Re: [gentoo-dev] Virtuals - required?

[Jason Stubbs]

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

On Sunday 27 June 2004 02:32, Thomas de Grenier de Latour wrote:
> With your solution at the contrary, everything depends on the
> order in which packages get installed. If user prefers Xorg, then
> he must do an "emerge (--oneshot) xorg-x11" before emerging gnome.
> Also, if he wants to clone his system, he has to instanciate
> virtuals (all his non-default choices at least) before emerging
> world.

It would be possible to keep /etc/portage/virtuals. Moreso, it would become 
possible to restrict it to virtuals. Try putting "sys-devel/gcc 
sys-libs/glibc" into it and then emerge -p gcc. It will show glibc.

>  - it would allow to inject virtuals. That could be a good thing.
> (I remember that being able to "emerge inject
> virtual/linux-sources" had been a request i've seen in the past
> on this list.) I don't know how that would play with the
> RESTRICT=metaebuild idea tho (depends how you implement it).

I haven't given this any thought, but I guess it could be done.

>  - it would be very handy to have a user tool to list
> candidates for a given virtual. Something like "equery
> instanciates virtual-pkg-spec".	It is straightforward to implement
> with current system (now that the information is available in
> aux_get), but seems harder in the context of your proposal.

Personally, I think it is easier with my proposal. Presently, it requires 
scanning for PROVIDE in every ebuild in the tree. With my proposal, it would 
only require checking the RDEPEND of the metaebuild.

>  - it may make packages cleaning a bit harder: With the old
> edb/virtuals system, it was easy to delete a few obsolete
> duplicates in the virtuals file, and then ask depclean to finish
> the cleanup a safe way. At the contrary, with your system, assume
> "virtual/foo" depends on "|| ( bar/pkgA bar/pkgB )", then install
> something that depends on virtual/foo (here, pkgA gets installed),
> and then install pkgB. Do an "emerge -p depclean", and see
> "bar/pkgA" is not listed despite it is not in world nor really
> needed anymore. Maybe that can be fixed in depclean code tho, i
> don't know.

That is a difficult problem to get around, but exists regardless of how 
virtuals are implemented. It seems like the first argument I've heard for a 
breadth-first rather than depth-first dependency resolver. This issue also 
exists (in a different form) in 2.0.51 but is easy to overcome by explicitly 
stating the desired virtual in /etc/portage/virtuals. The only way to fix it 
with my scheme would be to fix depclean (which is broken in many other ways 
as well...)

Actually, this problem is worse than you've described. app/fooA depends on "|| 
( bar/pkgA bar/pkgB )" and bar/pkgB is installed as a dep from app/fooB when 
app/fooA is emerged. Afterward, bar/pkgA is installed and app/fooB is 
uninstalled. depclean removes bar/pkgB and app/fooA more than likely breaks.

>  - also, i don't know exactly what would be the behavior of
> RESTRICT=metaebuild, but if the point is that the package
> don't appear at all in /var/db/pkg, then there is an issue:
> it makes impossible to track backward dependencies.
> We would then have packages that are:
>  * not in world
>  * not depended on by anything according to "qpkg -q"
>  * not candidate for cleaning according to "emerge depclean"

The main point of RESTRICT="metaebuild" is that it does not show up in emerge 
- -p and that only its RDEPEND is checked. Whether it be installed into the var 
db or not was undecided and something I hadn't given much thought to. I have 
no issue with copying it to the the var db.

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

iQCVAwUBQN4ZI1oikN4/5jfsAQLQ2gP/aQiK+D7cHU4Oyaa/+ISWUgUcVuZKQdhq
vXfte3DSbWdqsPvC1vH1JVth6OT4w/OZhk2Tx/B11UN+J4hXvy4JGN7BzGRBJw23
uRm6g7eaJTuFoXJTopRQIpE3Y7SAlpi2E+MYpguk2gaVfU8jsBH7rRwkgoI60u+O
BreYL9ay8qk=
=v7xi
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list