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 <hwoar...@gentoo.org>
> 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
