Heads up! Erlang package becomes modularized in Fedora.
 

Hello All!

CC to devel@lists.fedoraproject.org
CC to erlang-questions@erlang.org

I would like to attract attention those erlangers, who use Fedora and
especially those of them, who use Erlang from Fedora's main
repository. Others are safe :)

Since Erlang adoption steadily grows and more applications, written in
Erlang, becomes popular, people starts complaining about the way
Erlang is delivered in Fedora. One large bulk containing mixture of
erlang/c/java sources, beam-files, examples, which has heavy
dependencies like wxGTK and Java, is not that Average Joe wants when
he tries to install his favorite document-oriented database, yet
another web-server, xmpp-server or something similar.

The problem is that we try to offer users a package with as much
features enabled, as we could, so we can't simply disable some
functionality at a build time. All we really can do here is to split
one large package into pieces. Few of us (Fedora maintainers) briefly
discussed this situation, and there is a consensus, that we should
split off at least some parts of main Erlang package.

I did some investigation, and find a way to completely modularize
whole Erlang package. In a few words - main package consists of purely
virtual 'erlang' package and a dozens of sub-packages (from
erlang-appmon to erlang-xmerl - one sub-package for each
%{_libdir}/erlang/lib/* item). The main virtual package 'erlang'
depends on every subpackage, so if you prefer to install/upgrade
erlang by typing "yum install erlang" you won't see any difference.
What's new is a set of scripts to generate cross-subpackage
dependencies. The approach for dependency generation is very
straightforward and simple - with the addition to normal RPM
dependency generator, each ebin/*.beam file within each sub-package is
analyzed for imported and exported functions, and they are added (in
form of erlang(Module:Finction/Arity)) to the list of RPM provides and
requires.

Other visible change is a removal of c_src, java_src and erlang
src/*.erl files from subpackages. In fact, everything stored in /usr
is not intended for recompiling by user, so it's safe to remove these
files. If someone have any *technical* objections for doing this, it's
time to dispute this change. At the first try, I did very sensitive
mistake (already recovered) - unfortunately some *.hrl files, which
should be stored in %{module}-%{version}/include intentionally stored
in %{module}-%{version}/src . We can't do much here since many users
hardcode these paths in their projects, so I just leaved all *.hrl
files in src directory intact.

I also remove empty and *.o files and fixed some installation errors
with priv libraries, but these are minor changes.

I repeat and emphasize - I'll do my best to achieve full compatibility
with previous installations, and I'm pretty sure that all these
changes wont break anything. Also I'm sure that we need to push this
change into both F-12 and forthcoming F-13, since benefits are really
great (if everything will be done properly and careful, of course -
that's why I'm still testing every erlang-related package, included
(and even yet not included) in Fedora for possible regressions).
Fedora 11, EL-4 and EL-5 will remain unchanged.

List of affected packages:

https://fedoraproject.org/wiki/SIGs/Erlang#Current_packages

Any objections and commentaries are highly welcome!

--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

On Sat, Apr 10, 2010 at 8:56 AM, Peter Lemenkov <lemenkov@gmail.com> wrote:
>
> I did some investigation, and find a way to completely modularize
> whole Erlang package.

Sounds great!

> Also I'm sure that we need to push this
> change into both F-12

I object to this on general principle. Pushing sweeping changes to
infrastructure packages is not what stable updates are for.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

Le samedi 10 avril 2010 à 16:56 +0400, Peter Lemenkov a écrit :

> I did some investigation, and find a way to completely modularize
> whole Erlang package. In a few words - main package consists of purely
> virtual 'erlang' package and a dozens of sub-packages (from
> erlang-appmon to erlang-xmerl - one sub-package for each
> %{_libdir}/erlang/lib/* item). The main virtual package 'erlang'
> depends on every subpackage, so if you prefer to install/upgrade
> erlang by typing "yum install erlang" you won't see any difference.

So you are proposing a metapackage. Fedora has historically frowned at
metapackages, we prefer to create comps groups to bundle multiple
packages together.

The one problem a comps group won't solve is upgrade paths, but that can
be handled by a temporary metapackage

http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_pack ages#.28n:m.29_Many_to_many_replacement


--
Nicolas Mailhot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

2010/4/10 Colin Walters <walters@verbum.org>:

>> Also I'm sure that we need to push this
>> change into both F-12
>
> I object to this on general principle. *Pushing sweeping changes to
> infrastructure packages is not what stable updates are for.

This update is fully API/ABI compatible with previous monolithic
package and smoothly upgradeable from previous version, so I don't see
any problems here from user's point of view. From the packager's side
- every package, depending on erlang, will remain working.

To be honest, I also pursuing my own goals, when insisting on pushing
this update to F-12, since my primary working machines (on which I do
most part of Fedora-related tasks) are powerpc-based, and F-13 for
PowerPC still doesn't exist.

--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

Hello!

2010/4/10 Nicolas Mailhot <nicolas.mailhot@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.

Sorry, but this looks like purely non-technical argument for me (I
mean using verbs like "prefer", "frown" and so on). I, for example,
prefer meta-package, Fedora Haskellers prefer metapackage
(haskell-platform) too. My scheme introduces zero maintenance efforts
for those who are not interested in using modularized erlang package,
while your one (with existing for a while compatible package) will
definitely cause issues and complaints.

> The one problem a comps group won't solve is upgrade paths, but that can
> be handled by a temporary metapackage

In fact this raises more issues than solutions, so I still believe
that my proposed scheme is better than scheme with comps groups..

--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit :
> Hello!
>
> 2010/4/10 Nicolas Mailhot <nicolas.mailhot@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.
>
> Sorry, but this looks like purely non-technical argument for me (I
> mean using verbs like "prefer", "frown" and so on).

If you want fancy arguments replace it with "consistency". I don't
believe comps is dramatically better than metapackages (or the contrary)
but comps is the Fedora choice and our distribution is comps-oriented,
and it does not help our users if some package islands start using
different conventions from the rest of the distro.

If you want the full technical analysis just search the list archives
for "metapackages" "comps" it has been debated multiple times in the
past (at least twice a year) and I havn't the energy to do it again now.

--
Nicolas Mailhot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

Hi,

2010/4/11 Peter Lemenkov <lemenkov@gmail.com>:
> Hello!
>
> 2010/4/10 Nicolas Mailhot <nicolas.mailhot@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.
>
> Sorry, but this looks like purely non-technical argument for me (I
> mean using verbs like "prefer", "frown" and so on). I, for example,
> prefer meta-package, Fedora Haskellers prefer metapackage
> (haskell-platform) too. My scheme introduces zero maintenance efforts
> for those who are not interested in using modularized erlang package,
> while your one (with existing for a while compatible package) will
> definitely cause issues and complaints.

This is to maintain consistency with upstream. We also have a Haskell
Development group that you can install that is essentially the same
thing. Since haskell-platform is marketed as such, not to mention that
it is essentially a distribution package from upstream, it defies the
minimal expectations to not offer it. That said, could we do things
differently without confusing people new to Fedora, having a meta
package isn't a hard requirement either. Please don't confuse the
forest with the trees :).

-Yaakov
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

On Sun, Apr 11, 2010 at 2:27 AM, Nicolas Mailhot
<nicolas.mailhot@laposte.net> wrote:
> Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit :
>> Hello!
>>
>> 2010/4/10 Nicolas Mailhot <nicolas.mailhot@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.
>>
>> Sorry, but this looks like purely non-technical argument for me (I
>> mean using verbs like "prefer", "frown" and so on).
>
> If you want fancy arguments replace it with "consistency". I don't
> believe comps is dramatically better than metapackages (or the contrary)
> but comps is the Fedora choice and our distribution is comps-oriented,
> and it does not help our users if some package islands start using
> different conventions from the rest of the distro.

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.

This approach has worked well for us, and, at a technical level, if
done properly I don't see why it wouldn't work well for Erlang as
well.

-Chris

--
Chris Weyl
Ex astris, scientia
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

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@laposte.net> wrote:
> > Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit :
> >> Hello!
> >>
> >> 2010/4/10 Nicolas Mailhot <nicolas.mailhot@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:

http://lists.baseurl.org/pipermail/yum/2010-April/023241.html

...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@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up! Erlang package becomes modularized in Fedora.
 

On Mon, Apr 12, 2010 at 3:31 PM, James Antill <james@fedoraproject.org> wrote:
> 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@laposte.net> wrote:
>> > Le dimanche 11 avril 2010 à 10:06 +0400, Peter Lemenkov a écrit :
>> >> Hello!
>> >>
>> >> 2010/4/10 Nicolas Mailhot <nicolas.mailhot@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:
>
> *http://lists.baseurl.org/pipermail/yum/2010-April/023241.html
>
> ...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."

There's also the X meta package which is called xorg-x11-drivers from memory.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel