On Thu, 25 Oct 2007 22:14:40 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:

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

How is the problem solved now? Remember that I'm just proposing to
formalize existing assumptions (packages in "system" should state all
their dependencies explicitly). The answer is that there is no real
solution to that "problem", at least not without creating a huge mess by
enumerating all available profiles.
The real question is what "system" is supposed to be. Is it just a more
or less arbitrary list of packages chosen by the profile maintainer, or
does it have a global, predefined purpose, like defining the minimum
requirements for packages in the associated tree? In the first case the
second part of my proposal obviously doesn't work, as you can't make
any valid assumptions about "system". In the second case however the
purpose already mandates that the content of "system" is effectively
identical across different profiles.

Marius
-- 
[EMAIL PROTECTED] mailing list

Reply via email to