-----BEGIN PGP SIGNED MESSAGE-----
Hello Gentoo team,
the other SoC ideas of interest are projects #14  and #25 .
The idea is to automatically create ebuild descriptors that contain
metadata only. This way, server load on emerge --sync will be reduced,
since the ebuilds will only be fetched, if the package is about to be
In my opinion, this is the first step to take before trying to implement
the self-contained ebuilds. I think of them as Python eggs that contain
everything you need for installation (ebuild, patches, eclasses, sources).
Are these packaged ebuilds meant to be a replacement for the current
ebuilds in the long term? If so, the above mentioned reduction of server
load and network traffic would be diminished. Say you want to install 5
packages that use the eutils.eclass, you will have to download it 5
times (in a compressed archive of course).
A tool for creating the packaged ebuilds does not seem to cause much
trouble, either. What seems a bit more difficult to me, though, are the
changes to portage.
On the first glance, the rough specifications and tasks seem pretty
1. Create a tool that extracts an ebuild descriptor from an existing
ebuild (containing arch, version, dependencies, ebuild location,...)
2. Make portage work with the ebuild descriptors at first, then fetching
the required files
3. Create a tool that assembles an ebuild with its patches, sources, and
4. Make portage use the assembled archives
However, since I have merged TWO project ideas, I surely have overlooked
some traps :)
Probably I underestimated points 2 and 4?
Please, share you opinions.
Best regards and thanks in advance
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----