Re: [gentoo-dev] Virtuals - required?

[Thomas de Grenier de Latour]

Imho, this change would be a step in the wrong direction, because
it makes portage "less declarative and more imperative". Maybe
this programing paradigms analogy is a bit weird, so I will try to
explain what I mean here. 

For me, ideally, the set of installed packages (and their
configurations, versions, etc.) should depend exactly on a set of
user specifications, and not on the history of user actions (calls
to emerge). With such an ideal portage, it should be possible to
clone a system by installing a stage, copying the /etc/portage
content, and then doing "emerge world" (or "emerge $(cat
/etc/portage/sets/world)" maybe).

This is not currently true for several reasons (i won't detail
them all, that would be offtopic), and will probably never be, but
several recent changes in portage have been made that go exactly
in that direction. For instance, if one uses package.use and
package.keywords files instead of setting some environnement
variables on the command line, then the clone system he will
get using the above described technic will be closer to the
original. It makes things more deterministic and easy to
reproduce.

With that in mind, the introduction of /etc/portage/virtuals seems
to be yet another step in the right direction. With this file,
user can declare his non-default preferences for virtual packages
instanciation. During the initial installation, he can declare
very soon that he prefers Xorg to Xfree, and then call an "emerge
gnome", and that's Xorg that will be installed as a dependency.
Same for cloning a system, if the virtuals file has been copied,
then user's choices will be respected. 

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.

I think that the more portage behavior depends on past calls
to emerge history, the less user is in control of his system. At
the contrary, the more it depends on explicit declarations of user
preferences in config files, the more emerge behavior is
predictable and understandable. Now, you may not agree this
statements, in which case my point against your proposal is no
more valid. As i said, that's just my opinion, nothing more.


As a side note, some more random thoughts about your proposal:

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

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

 - 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. 
 
 - 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"
That would be a bit disturbing for users who wonder "why is this
package there?", and may also be a problem for some external tools
that rely on this backward deps. 


-- 
TGL.

--
gentoo-dev@g.o mailing list