Heads up! Erlang package becomes modularized in Fedora.
james at fedoraproject.org
Mon Apr 12 14:31:09 UTC 2010
On Sun, 2010-04-11 at 10:33 -0700, Chris Weyl wrote:
> On Sun, Apr 11, 2010 at 2:27 AM, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
> > Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit :
> >> Hello!
> >> 2010/4/10 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> >> > So you are proposing a metapackage. Fedora has historically frowned at
> >> > metapackages, we prefer to create comps groups to bundle multiple
> >> > packages together.
> Not to rehash anything, but a little more info on what other "package
> islands" are doing :)
> We've been doing this in the on the Perl side for a while now -- since
> we split "perl" out into multiple subpackages, we've had a "perl-core"
> metapackage that ties it all together, for those wishing to ensure
> that all parts of Perl traditionally thought of as "core" are
> installed. To my knowledge, there's never been any _technical_
> problem with this approach, and it transparently "Just Works" with the
> typical "yum upgrade" process.
It does "just work" with yum install and update, however there are at
least two significant annoyances:
1. "yum remove" is kinda broken, because it just removes the
metapackage. This is very confusing for new users, and can often lead
them down the wrong path. For a recent example I saw:
...even though this would be fixed the "new groups", I could be
convinced that the advantages of install/update override the
disadvantages of remove.
2. There doesn't seem to be any policy on naming, I've seen at least:
core | metapackage
git | git-all
nagios-plugins | nagios-plugins-all
perl | perl-core
tor-core | tor
wine-core | wine
...personally I think the scheme used by tor and wine is the most
prevalent, and most obvious to users ... but I'd be happy with anything
being "the std."
James Antill - james at fedoraproject.org
More information about the devel