[gentoo-dev] Re: Dynamic dependencies

[Duncan]

Ciaran McCreesh posted on Thu, 17 Sep 2015 20:31:36 +0100 as excerpted:

> On Thu, 17 Sep 2015 20:14:59 +0100 Markos Chandras <hwoarang@g.o>
> wrote:
>> could someone explain what the dynamic dependencies are in the context
>> of portage and ebuilds? because that does seem to be something
>> portage-internal specific in the way it handles changes in {,R}DEPEND
>> without revbumps. Where is this thing documented in the first place?
>
> Sometimes, Portage will sort of use the dependencies specified in an
> ebuild rather than the dependencies specified in VDB for certain
> operations under certain conditions and certain phases of the moon,
> except when it doesn't. This is a quirk left over from the olden days,
> when Portage could only handle the existence of one version of any given
> package, and so couldn't cope with there being something called foo-1.2
> in VDB and something else called foo-1.2 in the tree. This bug was
> largely fixed when env saving meant that eclasses no longer had to
> remain compatible with things in VDB, but traces of it still remain to
> cause confusion.

[There's discussion of a potential news item below.  People familiar with 
the dynamic-deps discussion in general may wish to skip to it.  See under 
the "Possible News item?" heading.]

Additionally, AFAIK, portage entirely disables dynamic-deps and uses 
static deps any time subslots are used.  Until the introduction of sub-
slots, portage did enough dynamic-dep calculation that devs could and did 
normally assume it, creating problems for static-dep PMs and the 
occasions when portage switched to static-deps.  Static vs. dynamic deps 
assumption still causes problems, but because subslots disable dynamic-
deps and they are now relatively common, static-deps have gradually 
become the general experience, and assumption of dynamic-deps has 
gradually become more of a problem than assumption of static-deps, the 
problem being that the cases in which one can avoid revbumping are 
slightly different with each, in ways that not everybody finds easy to 
understand, let alone keep in mind every time they write or change a dep.

So at some point, the portage devs proposed switching everything over to 
static deps, simplifying things for everyone and allowing them to drop 
the dynamic-deps code.  But back when it was originally proposed, subslots 
were new and not yet widely used, and people used to the old dynamic-deps 
way protested.  (And FWIW, certain political histories definitely didn't 
help.)

So council was called in, and it asked the portage folks to take some 
steps that, portage development being what it is, had the effect of 
slowing down and delaying things for long enough that, hopefully, people 
have had time to come to terms with the changes, and with a bit of 
familiarity, see static-deps aren't so bad, after all.

So now that subslots, and with them, static-dep handling, have become 
more common, hopefully people will see the benefits of getting rid of 
dynamic-deps entirely, thus simplifying things for both the portage devs 
and gentoo package maintainers in general, since there won't be two 
rather similar but annoyingly different in small details sets of deps-
resolution and corresponding revbump rules, to keep track of.

The one big remaining technical sub-problem to resolve is eclasses that 
specify rdeps, since with static deps, changes there can have pretty huge 
effects, potentially forcing many rebuilds.  (Personally, I don't see the 
virtuals thing as so much of an issue, since at worst, their effect tends 
to be rebuild of the single package filling the virtual, basically the 
same effect it has at the ebuild level.  Eclasses, OTOH...)  But that 
seems to be being worked thru in this thread, and a reasonable conclusion 
seems within reach. =:^)


Possible News item?

Beyond that, there's one other issue nagging at me, that I've not yet 
seen discussed, likely because it would have been premature, previously.

What's the effect on a normal user going to be, and should there be a 
news item?  As of now, there's a warning attached to the --dynamic-deps=n 
option in the emerge manpage, suggesting a fixpackages run if it's 
enabled.  If that's still recommended, switching to static-deps by 
default, and ultimately dropping dynamic-deps, really should trigger a 
news item suggesting that fixpackages run, for those with FEATURE buildpkg 
or buildsyspkg, anyway.

Additionally, from my own experience but AFAIK entirely undocumented, 
possibly due to my use of --with-bdeps=y, despite also having --newuse 
and consistently using --update --deep, switching to static-deps 
triggered a rebuild of a lot of packages depending on (IIRC) automake, 
because the way static-deps resolved it changed.  I didn't expect that 
because as I said, I normally update deep using newuse, so /thought/ I 
should be current, but apparently dynamic-deps wasn't as strict there as 
static-deps are.

I /think/ the --changed-deps option might avoid dealing with that 
manually now, so should it be enabled by default, and/or mentioned in the 
news item?  In any case, mentioning in the news item that a few extra 
rebuilds might be expected with this upgrade, and/or suggesting they be 
done previous to it (suggesting a --changed-deps run) could be wise.

Meanwhile, --changed-deps also invokes --selective by default, which will 
be a big change of behavior for many.  If --changed-deps is suggested in 
the news item (or becomes the default), the effect of --selective 
probably needs discussed as well.

Which probably is too much to easily fit a news item.  In such cases, the 
news item generally becomes a brief overview, with a link to (now) a wiki 
page, with further detail.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman