[gentoo-dev] Re: don't rely on dynamic deps

[Martin Vaeth]

Ian Stakenvicius <axs@g.o> wrote:
>
> The main issue that I see is
> - -how- VDB should be adjusted based on what changes are made to the
> ebuilds.  For instance, if minimum versions of deps are adjusted
> in-place, should vdb be updated to match?  what happens if the minimum
> version of the currently-installed dep is below the new one?  etc. etc.

All these problems disappear with minor revisions:
You have to "install" the minor revisions just like any major revision,
just that some phases will be shortcut.
In particular, if the new dependencies are not satisfied, you get
conflicts as usual if you would want to upgrade to a new version
with dependencies not being satisfied.

> Also, in theory an EAPI bump with nothing else changing should be
> re-generatable in the VDB, but i have a gut feeling (no evidence, just
> a feeling) that going from say, EAPI2 to EAPI5 without doing some of
> the phase functions again (ie 'merge', maybe there are others that can
> affect VDB?) will result in a different VDB from a regular rebuild.

As far as I can see, the phase functions which can be skipped
are those from "EbuildExecuter".
If a package is special and needs to execute these functions,
then this package must not use minor revisions and needs to
be recompiled. Howeer, these packages should be rather rare;
I cannot even imagine a reason why this should be necessary.

For "merge" only the regeneration of CONTENTS in /var/db/pkg
should be skipped.

Concerning the confusion with "minor" revisions, I think that
just the version comparison function in portage needs to be tuned to
ignore minor revisions unless an extra parameter "minor" is passed:

This extra parameter is essentially only needed in the "best"
function and in the check whether phases need to be run.
The version comparison function should just return
-2, 2, 0 (if minor is not passed or False)
-2, 2, -1, 1, 0 (if minor True; the values +-1 mean that
*only* the minor revision differs).

For some parts (some eapi support, parts of EbuildExecuter and
version comparison), I have already some patches ready
for portage.  However, I have almost no free time, and I am
not familiar enough with python and portage to do the rest
in a reasonable time
(e.g. I cannot put some writable attribute to EbuildExecuter
since apparently some python hack is used in portage which I
do not understand).
If there is interest, I can post my patches so far. Where?

What is not included in these patches, and I will probably
not find the time to include it:

1. The actual skipping of phases (since all my attempts to
   set some flag led to the python error that all
   attributes of EbuildExecuter are readonly :( )
2. The modification of the merge phase to not regenerate
   CONTENTS
3. Reporting an error if minor versions are used with
   non-matching EAPI. Surprisingly, this needs a bigger
   rewrite, since the code generating the regular expression
   for the version handling is currently not appropriate to
   such an extension.
4. Updating of .tbz2 files - this is certainly a bigger work.
5. In particular, the patches could not be tested yet...

I would suggest to postpone 3. and 4. until the decision
is made...