Re: [gentoo-dev] Virtuals - required?

[Thomas de Grenier de Latour <degrenier@easyconnect.fr>]

On Sun, 27 Jun 2004 14:41:47 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> virtual/x11:RDEPEND="|| ( x11-base/xorg-x11 x11-base/xfree )"
> portage/virtuals:virtual/x11 x11-base/xfree x11-base/xorg-x11
> expand to "|| ( x11-base/xfree  x11-base/xorg-x11 
>                 || ( x11-base/xorg-x11 x11-base/xfree ) )"

That a good idea, but it works well only because the virtual dep
formula is a global disjonction. But what if for instance someone
writes an alsa virtual that looks like this:
  RDEPEND="|| ( media-sound/alsa-driver              
                >=virtual/linux-sources-2.6 )
           media-libs/alsa-lib"
Then the user who wants his driver to be provided by kernel2.6
should probably write this in is virtuals file:
  virtual/alsa  \
     ( >=virtual/linux-sources-2.6 media-libs/alsa-lib )
so that the RDEPEND is transformed into:
 "|| ( >=virtual/linux-sources-2.6 media-libs/alsa-lib )
     ( || ( media-sound/alsa-driver 
            >=virtual/linux-sources-2.6 )
       media-libs/alsa-lib )"

Imho that's a bit too complicated, that's why i think
expressiveness should be limited to a global disjonction. That
said, it may be done by policy instead of being enforced by
the code.

On the same kind of idea, i was thinking about an helper tool for
/etc/portage/virtuals (what ufed is to the USE var). If you are
sure that virtuals dep is just a disjonction, then, for a given
virtual, the tool can present to user the list of possible
choices, and user only have to sort his prefered packages. But if
you allow arbitrary formulae, then such a tool becomes harder
to write and to understand for the user. 

> > That say, what is still hard is to know what virtuals a
> > given package instanciates (which is required for instance for
> > correct implementation of the buildsyspkg feature).

Just to explain this point a bit more, have a look on bug #34964:
The goal was to enable buildpkg for system ebuilds. An issue was
that in profile, there are some system packages specified as
virtuals. The implementation of this "buildsyspkg" feature that is
currently in portage is broken in such cases (if profile ask for
virtual/glibc, the sys-libs/glibc won't be recognized as a system
package). Now that PROVIDES is an aux_get key, that would be easy
to fix. But at the contrary, with your system, this link from a
concrete package to the virtuals it instanciates disappears, so it
can no more be fixed. That's a rather minor issue tho. 

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 (and a
few other like this, some of which are conditional, etc.). With
your system, every single kernel sources packages will have to be
listed in the virtual ebuild.

> Assuming no other packages come into play, hexxagon is now
> broken as gtk+ would be unmerged. I think there's absolutely no
> way to get around this other than to record what the package was
> built against. What I was saying earlier is that this is a
> current problem which must be fixed regardless of any change to
> virtuals.

Ok, now i understand better. and you're right that once the
virtuals preferences of the user are integrated in the dep
formula, as you've proposed, then it is no more special case
for depclean.

> > Imo, it should appear in db, but as a special case
>
> This is very easy. Just check for RESTRICT="metaebuild".

Yes, i agree it seems rather straightforward to add this special
case. 


-- 
TGL.

--
gentoo-dev@gentoo.org mailing list