Re: [gentoo-dev] Virtuals - required?

[Thomas de Grenier de Latour]

On Mon, 28 Jun 2004 22:02:24 +0900
Jason Stubbs <jstubbs@g.o> wrote:

> >  "|| ( >=virtual/linux-sources-2.6 media-libs/alsa-lib )
> >      ( || ( media-sound/alsa-driver
> >             >=virtual/linux-sources-2.6 )
> >        media-libs/alsa-lib )"

Oops, what i actually meant was :
  "|| ( ( >=virtual/linux-sources-2.6 media-libs/alsa-lib )
        ( || ( media-sound/alsa-driver
             >=virtual/linux-sources-2.6 )
          media-libs/alsa-lib ) )"

>From $RDEPEND and $USER_PREFS, one would create:
 NEW_RDEPEND="|| ( $USER_PREFS
                   ( $RDEPEND ) )"

> Actually, you're example above reminded me of bug #25013.
> Specifically the comments toward the end relating to the
> kde.eclass. As these meta-packages are versionable, this scheme
> would be perfect to handle that (and probably a whole lot of
> other simple eclasses as well).

You mean, depending on a metaebuild instead of adding some deps
from an eclass? If that's so, agreed, that makes sense. 

> Dependencies of system packages that aren't listed in system
> would also be exempted.

True.

> My current implementation of this feature in the API (the end
> goal is all logic in emerge being out and reimplemented) scans
> each atom in system and checks if the package to be merged
> matches it.

Sounds perfect. By curosity, how is the cost of this check?
(and do you cache the result of this system deps tree
calculation, to reuse it for the next ebuild?)

> > A maybe more important one if PROVIDES disappears is that you
> > loose some convenient shortcuts when using eclasses. For
> > instance, for kernel sources, the eclass has
> > PROVIDES=virtual/kernel
>
> True...

This makes me think about an intermediate solution:
 - keep the current PROVIDE in ebuilds syntax, and "virtuals" file
in profile
 - makes emerge generates a set of virtual metaebuilds each time
it rsyncs (using this PROVIDE information plus the virtuals file
in profile)

In terms of fonctionnalities, this system would be almost
equivalent to what currently exists in portage:
 - no need for a kernel dev to edit virtual/kernel.ebuild each
time he makes a new kernel available
 - PROVIDE in eclasses would still be possible
 - virtuals would be only some lists of alternatives, just like it
is currently
 - an ordering of this alternatives can be specified at profile
level profile

Some elements of comparaison with your proposal:
 - it would be less expressive (no more virtuals depending on
sets of packages for instances), but imho this simplicity is also
a good thing
 - it would be almost equivalent in terms of code. The handling in
deps calulation is just the same, and hence it would bring the
same speedup and simplifications. The only difference is the
metaebuilds generator to write, but i don't see major difficulty
here
 - it would need the cache format change that you were avoiding
 - virtual versioning also is possible in this scheme

Well, i'm not sure how good or bad is the idea, it came while
writing this mail, so i've not thought much about it yet.

> > (and a few other like this, some of which are conditional,
> > etc.).
>
> That behaviour is actually broken.

In the case of kernel.eclass, i think it's working correctly
because the conditions are actually about some statically defined
variables($KV and $ETYPE). Thus, for a given ebuild, it will
always evaluate the same whatever the user config is. 
  At least, this is true as long as bash is used to retrieve this
values. I think i've read that other simpler but faster parsers
may be used in the future, in which case such bash constructions
would become an issue.


> Thanks for this discussion, by the way.

My pleasure :) I like to brainstorm a bit around portage, i just
regret i don't currently have time to also participate with
code... Btw, if you want to continue this discussion, be patient
cause i will be offline next two or three days. 

Regards,

-- 
TGL.

--
gentoo-dev@g.o mailing list