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

[Alec Warner]

On 10/24/07, Marius Mauch <genone@g.o> 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

ok

> 2) it implements a redundant visibility filter as package.mask is also
> available in profiles

ok

> 3) the syntax for defining the "system" set plain sucks

not really relevant

> 4) the name doesn't really say anything about the purpose

not really relevant.

3 and 4 are documentation problems, not necessarily problems within
the current implementation.

>
> 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.

I'm going to discuss a bit your implementation below, since you
address what you are trying to solve here.  My main problem is that
given a tree (such as gentoo-x86) it may have one or more profiles
with one or more sub-profiles (children).  These profiles may contain
a set of packages that make up 'system'.  The ebuilds DEPEND (or
RDEPEND or whatever) on this set of packages existing.  The problem I
see with your solution is that it doesn't address different system
sets in different profiles.  Now in practice this isn't much of a
problem within gentoo-x86 (most profiles have similar system sets).
However it places a certain onus on any profile in a given tree, it
must have a system package 'similar' enough to other sets in
functioning profiles; otherwise breakage is likely to occur.  How
would you address this in your system?

>
> 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?
>
> Marius
>
> --
> Public Key at http://www.genone.de/info/gpg-key.pub
>
> In the beginning, there was nothing. And God said, 'Let there be
> Light.' And there was still nothing, but you could see a bit better.
>
>
-- 
gentoo-portage-dev@g.o mailing list