Re: [gentoo-dev] Virtuals - required?

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

On Sun, 27 Jun 2004 09:47:25 +0900
Jason Stubbs <jstubbs@gentoo.org> 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. 
  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.

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

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

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

> (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?

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

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

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list