guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Packaging vs. Maintaining (was: [PATCH] xscreenshot and imagefile)


From: Jeff Mickey
Subject: Packaging vs. Maintaining (was: [PATCH] xscreenshot and imagefile)
Date: Thu, 30 Jul 2015 12:31:35 -0700
User-agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu)

* Mark H Weaver <address@hidden> [2015-07-29 19:58]:
> Do other people think that such programs belong in Guix?

I've only gotten 1 package into guix so far, so take my thoughts with a
grain of salt.

I liked the Arch model[0] when I was a dev: core, extra, community +
AUR.[1] The AUR I would credit with a vast amount of Arch's early
popularity as it got lots of software packaged before devs had time to
get to it, but it includes lots of non-free software.

To show how drastic their split is, here are the arch package numbers
for i686:

Core - 209 packages. (linux, linux, bash, mkfs, ssh etc)

Extra - 3141 packages. (emacs, vim, X, firefox, kde/gnome etc)

Community/AUR - 61251 packages. 4014 audited binary packages, 57237!
source packages that are unaudited and pacman doesn't build them for
you.

There are many pieces of software. There is only a finite amount of
development commitment. Arch namespacing their packages by dev
commitment is a successful example of managing this.

Guix could use a policy (and package namespacing?) that delineates this
commitment so that contributions can be accepted without
misunderstanding.

My random stab at a delineation:

- 'core' and 'extra' - I like arch's definition for these. Highly
  selective and essential that all packages in core are tested and in
  working order. Extra is a statement of the devs commitment currently
  working on guix, and includes the vast majority of the GuixSD software
  stack.

- 'community' - Due to guix's source based architecture, this is the
  software that meets guix's licensing goals, coding standards, and
  compiles/runs. The packages may or may not be up to date, and are not
  actively maintained by guix developers, but are popular with the
  community and built with hydra.

There is room for another even wider set, a guix-users.git or something
that contains the long tail of packages like the AUR. With
GUIX_PACKAGE_PATH this may be as easy as a git repo with some base
submission guidelines.

Sorry that went long - just some thoughts.

  //  codemac

[0]: https://wiki.archlinux.org/index.php/Official_repositories
[1]: https://aur.archlinux.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]