Re: [gentoo-portage-dev] RFC: replacing "packages"

[Andrew Gaffney]

Marius Mauch wrote:
> As package sets are mostly done now, I'm starting to think about
> something else. One of my pet peeves with portage is the "packages"
> file in profiles, for several reasons:
> 1) it has two completely independent purposes
> 2) it implements a redundant visibility filter as package.mask is also
> available in profiles
> 3) the syntax for defining the "system" set plain sucks
> 4) the name doesn't really say anything about the purpose
>
> Another issue that isn't directly related, but covered by the proposed
> solution below, is the so called "implicit system dependency" in
> ebuilds, which doesn't really exist. It only an assumption by people
> that the "system" set is satisfied before an ebuild is processed, so
> its contents don't have to be listed in *DEPEND. If a user breaks that
> assumption by not regulary ensuring that "system" is satisfied bugs can
> occur. Another issue is the informal exception when system items are
> allowed to/must be listed in *DEPEND, IMO that should be formalized.
>
> To solve both issues I propose the following system:
> Profiles can contain the files "system.depend" and "system.rdepend"
> whose combined contents make up the "system" target. If any of those
> two files exists the "packages" file is ignored. The syntax should
> either be the same as package.mask or, if desired, also allow complex
> atoms (use-conditionals, any-of constructs).
> The second part would be that portage implicitly adds the content of
> the files to the DEPEND or RDEPEND setting of each ebuild unless it
> contains RESTRICT=system-deps. Obviously this would have to be tied to
> a new EAPI version. (an undefined cornercase here is if a profile does
> not contain the new files, not sure how that should be handled)
>
> Benefits:
> - we get rid of all the issues outlined at the top
> - should make it easier long-term to setup a no-compile system that only
> installs binary packages due to separation of build- and runtime deps
> in "system"
>
> Problems:
> - obviously it has to be implemented first
> - no obvious solution for stacking rules (e.g. child uses system.*, but
> parent profile only has "packages")
> - some people might rely on the "packages" file
>
> So, comments?

I like the idea overall. I dislike the "packages" file for many of the same 
reasons that you pointed out. However, I have a few questions/concerns with your 
proposal.

For packages that are in the "system" set, wouldn't adding the contents of 
system.{,r}depend to {,R}DEPEND cause problems in dep resolution? Would there be 
a way to prevent the contents of these files from being added for packages that 
are themselves in these files?

How is the "system" set constructed from these files? Would they simply be 
concatenated (minus duplicates) and treated like the old "packages" file (minus 
the magic visibility filtering)?

-- 
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer             Catalyst/Installer + x86 release coordinator
-- 
gentoo-portage-dev@g.o mailing list