Re: [gentoo-dev] Virtuals - required?

[Jason Stubbs]

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

On Sunday 27 June 2004 12:03, Thomas de Grenier de Latour wrote:
> On Sun, 27 Jun 2004 09:47:25 +0900
> Jason Stubbs <jstubbs@g.o> wrote:
> > It would be possible to keep /etc/portage/virtuals.
>
> Maybe that's possible, but i don't see how. The system you've
> proposed is much more powerful than the current one, and that's
> a problem: a virtual is no more a simple choice between several
> possible packages, thus user preferences can no more be a simple
> (set of) package(s) choice.

When a metaebuild is encountered, check /etc/portage/virtuals for a match. If 
one exists, prepend the settings to the RDEPEND. Maybe embed is a better word 
than prepend. Here is what I'm thinking:

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

>   To make use of a simple virtuals file like the one currently
> available, you would have to limit expressiveness of the
> dependency formulae you allow in virtual ebuilds. You must allow
> "|| ( A B C )" but forbid "|| ( A && ( B C ) )".
> Imo, you can't really use the usual (R)DEPEND but must define a
> new kind of formula where only depend atoms and arch? or useflag?
> statements operators are allowed. The list of subformulae would be
> interpreted as a global disjonction.

I don't see why the expressiveness must be limited. If there is actually a 
need, I'll throw this idea away as the whole point is code simplification.

> > 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.
>
> Here again, the problem is the expressiveness of your model. If
> you don't require a simple disjonction of dep atoms but allow an
> arbitrary depencies formula, it becomes hard to calculate its set
> of models. In general case, the best you can answer is the formula
> where "arch?" or "useflag?" statements have been interpreted. It
> means you have to expect answers of the form "A or (B and C)" for
> instance. That was simply impossible with the original virtuals
> system, that's why i think it was easier (answers would have
> always been of form "A or B or C").
>   But if you take the simplified depend formulae i've described
> above, then i agree it becomes easy.
>   That say, what is still hard is to know what virtuals a given
> package instanciates (which is required for instance for a correct
> implementation of the buildsyspkg feature).

I don't understand the problem you're describing here.

> > >  - it may make packages cleaning a bit harder: [snip]
> >
> > That is a difficult problem to get around, but exists regardless
> > of how virtuals are implemented.
>
> Exists a bit less with <=.50 implementations: with this versions,
> it's easy to edit the edb/virtuals file to delete a few obsolete
> duplicates, and then depclean works fine to finish the cleanup a
> safe but effective way.
> I've not experimented much with current .51_pre tho, so i won't
> comment on this one.

.51_pre removes /var/cache/edb/virtuals altogether and scans
/var/db/pkg/*/*/PROVIDE instead. Hence, the order of the virtuals is 
arbitrary. /etc/portage/virtuals can still be used to do what your describing 
here though.

> > The only way to fix it with my scheme would be to fix depclean
>
> Yes. It would need addition of special heuristics for
> "metaebuilds" dependencies. But for that to work, again, you need
> to restrict expressiveness of the dep formula. For instance,
> assuming deps are of the form i've described above, then you can
> make a depclean that search the smallest solution to this
> constraints set:
>  - at least one of the possible packages must be kept;
>  - if one is in world, then keep at least this one;
>  - if one is depended directly by another package, then keep at
> least this one;
>  - if none of the above two cases is verified, then keep at least
> the first packages from the list of candidates.
> (or something like that...)
> My point is that if packagers start to write virtuals with complex
> dependencies formula (like "|| ( A && ( B C ) )"), then this
> optimal calculation of what must be kept and what can be cleaned
> becomes much more tricky.

See my comment below. The special heuristics are needed already...

> > (which is broken in many other ways as well...)
>
> Agreed...
>
> > 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.
>
> Well, yes, that's also bad, but at least this one is right
> and optimal from the specified dependencies point of view. In
> the case i've described, that was not even true.
> The issue in your example is more yet another proof that binaries
> depencies are more strict than ebuilds dependencies can be. That's
> close to the openssl 0.9.6 vs 0.9.7 issues (ie. packages can build
> against one or the other, but once built they can run only with
> the right one). Or did i misunderstood your example?

You misunderstood. Take this example from games-board/hexxagon-0.3.1:
DEPEND="|| (
                readline? ( sys-libs/readline )
                gtk? ( =x11-libs/gtk+-1* )
                sys-libs/readline
        )"
This package can build against either sys-libs/readline or x11-libs/gtk+-1* 
but not both. The USE flags complicate it for purposes of the example, but 
almost all ebuilds that use this syntax are similar.

emerge -C sys-libs/readline
emerge =x11-libs/gtk+-1*
USE="-readline gtk" emerge =games-board/hexxagon-0.3.1
emerge sys-libs/readline
USE="-*" emerge depclean

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.

> > 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.
>
> Imo, it should appear in db, but as a special case (that would
> hence not be backward compatible):

It would be backward compatible as long as the virtuals are kept in the 
profiles for some time as well. Portage checks if a package atom is virtual 
before checking any database.

>  - appear, because it's a necessary link in the backward
> dependencies calculation.
>  - as a special case, because its presence should not be enough to
> satisfy a dependency by itself. Think of emerging something that
> depends on virtual/jre, then decide the default jre (lets say
> blackdown-jdk) sucks and uninstall it, and then install something
> else that depends on virtual/jre... result is a non-working
> package. I know that you can't track deep dependencies every time
> a package gets installed in current portage. Technicaly, this is
> just one more case where a broken package is used to satisfy a
> dependency just because it's there. That's nothing new, but it's
> much more error prone than with usual packages because user don't
> really know about this virtuals and hence is not really
> responsible for the mess he introduces when he uninstall, for
> instance, blackdown-jdk.

This is very easy. Just check for RESTRICT="metaebuild".

> So what i suggest is that metaebuilds appear in db, but when they
> are used in a dep calculation, the algorithm always goes one step
> further(just like with -u) to check whether at least one concrete
> packages is really there. And if it's not, then pick the best
> concrete package taking /etc/portage/virtuals and ordering of the
> depend formula into account (just like if the virtual wasn't
> installed).

One other thing as well... /var/db/pkg is not currently used for dep 
calculation. When it does become used, $PORTDIR's copy of the metaebuild 
should be used instead if it exists.

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

iQCVAwUBQN5eHVoikN4/5jfsAQK6igP+PfUJu4R79Jio1B63UBUVBvogqbzY7pUS
MuKxBlQUcXqMBOOvFkX/AufzpXvHjMYaEs5Kizb/leYVUy9+7coq/eLZLSc2v/Hf
7jLMLCVOmCoiu9KJdMZ2O7gdmQHzlSiODTBcSnwo4308z0wNmDN8SQU1YUsHqxJ3
WbxjW5L4q8Q=
=6fug
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list