[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
- Re: [PATCH] xscreenshot and imagefile, (continued)
- Re: [PATCH] xscreenshot and imagefile, Guix-Bot, 2015/07/28
- Re: [PATCH] xscreenshot and imagefile, Guix-Bot, 2015/07/28
- Re: [PATCH] xscreenshot and imagefile, Guix-Bot, 2015/07/28
- Re: [PATCH] xscreenshot and imagefile, Guix-Bot, 2015/07/28
- Re: [PATCH] xscreenshot and imagefile, Mark H Weaver, 2015/07/29
- Re: [PATCH] xscreenshot and imagefile, Alex Kost, 2015/07/29