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

[Duncan]

Kent Fredric posted on Wed, 23 Jul 2014 06:44:57 +1200 as excerpted:

> Ok, we can side step this discussion partially:
>
> Lets pretend for a moment dynamic deps get banned.
>
> People will still unconsciously make that mistake and things will still
> break when they do.
>
> So we'll probably need a repoman check that is smart enough to know "X
> is modified" and compare the DEPEND fields with the previous incarnation
> prior to commit, and then at very least, warn people doing `repoman
> full` that they've modified the dependencies, and that a -r1 bump is
> thus highly recommended.
>
> And that check can be added *now* prior to banning/disabling dynamic
> deps.
>
> And people who want to pay attention to that warning can start doing it
> before policy dictates they must.

Be aware that with eclasses generated deps taken into account, this 
/could/ trigger a LOT of arguably unnecessary revision bumps.

Right now I'm trying emerge --dynamic-deps n --update --deep @world, 
and...

Due to dynamic-deps and the (default) WANT_AUTOMAKE=LATEST (or whatever 
it is) stuff in the eclasses, I only have automake slots 1.11 and 1.14 
installed here, but I still have well over 100 packages originally built 
with automake:1.13, that if I turn off dynamic-deps either need it pulled 
back in, or need to be rebuilt to pull in the automake:1.14 dep.

I guess that's a variant of category 2 in the wiki list.  It's a minor 
build-only dep change that doesn't need to be propagated immediately as 
the package is already installed, with dynamic-deps applying it 
immediately, but static-deps wouldn't apply it until a rebuild.  As long 
as the older automake slot remains around to fill the dep, not a problem.

Of course for users the fix is simple and what portage recommends, simply 
pull automake:1.13 back in (or don't let it be unmerged in the first 
place) and don't worry about it.

I decided to go the rebuild route instead, here, and once I decided the 
number of rebuilds wasn't going to be easy to do with --tree giving me 
one at a time, I concocted a pipe involving bzgrep environment.bz2 to 
list them all so I could rebuild them in parallel, then did a wc -l on 
the output to get a count.

But a repoman dynamic-deps checker might have flagged all those 125-ish 
package for revision-bump when automake:1.14 was introduced and thus 
became a dependency candidate.

And I'm on ~arch, doing --deep --newuse @world updates routinely, with a 
not insignificant portion of my packages being live-ebuilds, so many of 
the package originally built with automake:1.13 have certainly been 
rebuilt by now, here.  But I see a distinct possibility of an automake 
slot bump triggering thousands of rev-bumps, often to all available 
versions of a package at once, tree-wide.


Meanwhile, one personal benefit to this discussion is that at least I 
understand now why merging a binpkg the other day pulled in some automake 
slot that depclean immediately wanted to remove.  Binpkgs are static-deps 
and that one must have been built with that automake slot, but of course 
depclean was using dynamic-deps, so...  Now I have a proper explanation 
for the behavior. =:^)

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