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
