Re: [gentoo-dev] Virtuals - required?

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 28 June 2004 10:43, Thomas de Grenier de Latour wrote:
>   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.

We're also trying to prevent portage relying on policy. Policies require a 
strong QA team and that we ain't got. However, I agree that the above is too 
complicated.

The other option is to just treat user's virtual settings as a replacement.
Cases where there are no brackets or any other notation could be treated as 
being inside "|| ()" for backward compatibility.

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

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

I've almost finished an API for portage that will make this sort of thing 
relatively easy. If you check it out, the support isn't there yet. By telling 
me what was needed, you just inspired me on how to support it. :)

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

I was aware of the feature and am using it but haven't really looked into the 
implementation. However, there is another issue if it's as you described. 
Dependencies of system packages that aren't listed in system would also be 
exempted. This is a really bad thing, especially if you've built coreutils 
with USE="acl".

I would think that the best way to implement this feature is to look at the 
dependency graph and build a package for anything that was brought in via an 
atom in system.

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

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. Meta-ebuilds shouldn't make 
that any more difficult.

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

> (and a few other like this, some of which are conditional, etc.).

That behaviour is actually broken. There should be no conditionals whatsoever 
in the global scope of eclasses or ebuilds. This is a condition of the 
caching that portage performs and having conditionals in the global scope 
just means that dependencies are calculated using incorrect data.

> With your system, every single kernel sources packages will have to be
> listed in the virtual ebuild.

In a way it simplifies it as well, though. For example, many of the kernels 
that inherit kernel-2 and get that automatic PROVIDE have KEYWORDS that 
severely limit the architecture that it can run on. With a ufed-like virtuals 
editor you'd have to check the KEYWORDS of each one to ensure that the 
choices are valid. This way, invalid ones would be gotten rid of in one shot.

Thanks for this discussion, by the way. Most of these issues hadn't entered my 
head whatsoever. If I do make a patch, it'll be well forethought. :)

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQOAW41oikN4/5jfsAQKtJAP9Htz71ff6aeB8a5YW2rlYSrfESOTy3rg6
R2ElRoGi4k+IxNj2pq6pmHvFxv0lHCNgRIqhuhy/FOCYxmyZMqet/VVFs7UUbVqS
nv16HqS+On41rfoCO5mxsoDnkBxMcQp1Dba5YJVZKXNs7AH1Nmbq9kTri/x2oq8j
0Rj0gI7ByLU=
=Xpkx
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list