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

[Duncan]

Paweł Hajdan, Jr. posted on Sun, 27 Jul 2014 16:56:17 +0200 as excerpted:

>> One thing I would question in that table is "applied immediately (but
>> can break hard when dynamic-deps stop working))."  How can dynamically
>> removing an "unused dependency" cause something to break, setting aside
>> bugs in the package manager?  If removing a dependency causes something
>> to break, how can it be "unused?"
>
> Yeah, I was also wondering about this.


I believe what is being discussed there is the following (as I understand 
it):

1) Foo incorrectly deps on bar, and doesn't actually use that dep for 
anything.  Say it was a historical dep that upstream forgot to remove in 
the docs when they removed the dep, and the (gentoo) maintainer didn't 
detect it initially.

2) User installs foo with the incorrect dep, thus pulling in bar.

At this point use has an unnecessary package installed but is otherwise 
fine, deps are wrongly pulling it in.

3) Foo maintainer detects the error (upstream removed the dep in the 
unreleased version and maintainer realizes it wasn't needed in the 
current version either) and removes the dep on bar, but since it was 
unused anyway and thus doesn't affect the package as installed (except in 
vardb), he takes advantage of dynamic-deps and no revbump is done.

At this point, user has an unnecessary dep that portage has just been 
told about due to dynamic deps, and will unmerge it at the next depclean, 
but the user's dep-tree is still self-consistent and everything's fine.

4) Due to dynamic-deps, portage depcleans bar.

Due to dynamic-deps, the user's dep-tree is still consistent and 
everything's fine.

5) Since nothing in the tree needs bar, it is removed.

Due to dynamic-deps, the user's dep-tree is still consistent, because the 
in-/usr/portage foo.ebuild doesn't say anything about bar since #3.

6) Finally, foo is removed from tree.

** User isn't ready to get rid of foo yet, but user's dep-tree just blew 
up, because now portage falls back to the static vardb from original 
install, and that still says foo deps on bar, which is nowhere to be 
found!

What's worse, the usual trick of digging the ebuild out of vardb and 
putting it in the user's overlay to shut portage up and let the user keep 
foo doesn't work, because the vardb ebuild has an unsatisfied dep.

With the repeated caveat that this is as I understand it, if the above is 
clear along with the implications, you can stop reading here.  The below 
simply expands on the above and its implications...

The "breaks hard" bit can be applied for two reasons.  First, exactly as 
I said above, the user's now SOL -- they had no warning things were going 
to break and now it's too late to do anything about it (unless they're 
advanced enough to figure out how to dig the last, corrected ebuild 
version out of a snapshot or the cvs attic, or to figure out that dep 
isn't actually needed on their own, and edit the ebuild they pulled out 
of vardb accordingly).

Second, "breaks hard" can apply when a whole set of related packages were 
removed at once, all with the same bad dep.  Consider for instance 
someone with kde-4.11 installed and how deeply dependent typical kde 
ebuilds tend to be on the kde eclasses.  If the bad dep was in an eclass 
and applied to say 200+ kde packages the user may well have installed, 
then got corrected such that dynamic-deps killed the bad dep, then all of 
kde-4.11 was removed from the tree at once...  A user may well find out 
they have 200+ broken deps at once!  "Breaks hard", indeed!


Now we look at the same set of triggering events with static deps.  There 
are two cases, depending on whether the foo maintainer accounted for 
static deps and did a revision bump at step 3 or not:

With a revision bump at step #3, at step #4, before the user can do the 
depclean, they'll have to do the revision upgrade.  The aftermath of step 
#6 will then be hugely different as the vardb copy will have the bad dep 
removed as well.

If the foo maintainer didn't do a revision bump, with static deps the 
user will have never depcleaned bar in step #4 as the vardb deps still 
say it's needed.  So when foo is removed in step #6, again, no big deal.  
Sure the user had a useless dep installed the whole time, but when foo is 
removed from tree, fine, the user's dep-tree remains self-consistent and 
no blowup.  And the user remains free to dig that ebuild out of vardb and 
install it in the overlay again, at least temporarily, to keep portage 
from yelling about it until the user has time to find an alternative to 
the package, or to upgrade to the new version (kde 4.12 or 4.13 in my 
mass-breakage example).  Reinstalling may or may not be possible 
depending on how much the ebuild depended on eclasses and what had 
happened to them, but keeping the same thing installed at least 
temporarily should be fine.

And the static-deps case of the user not upgrading in a timely manner and 
thus skipping step #4 entirely, resolves exactly as if the maintainer 
hadn't done a bump.  Useless dep installed the whole time but no breakage.

To complete the alternatives-tree, the no-window-update scenario with 
dynamic-deps would fall back to static/installed when the user updated 
after both packages were removed, and if an eclass wasn't involved, 
pulling the ebuilds out of vardb to stick in the overlay temporarily 
should still shut up portage, and the user could even rebuild from his 
overlay copy.  But if an eclass was involved with that dep, however, 
pulling those ebuilds out of vardb and into the user overlay would 
trigger dynamic deps again, and what would happen then would depend on 
exactly how the eclass had changed.  If the eclass had simply removed the 
bad dep then the effect would be extending the correction window, since 
with dynamic-deps that new information would now be used, allowing bar to 
be unmerged even with foo still merged.  But if the eclasses had been 
updated to remove the old logic entirely (in the kde case, if the eclasses 
had their 4.11 logic removed already), then while portage would fall-back 
to the static deps as long as the ebuild wasn't available, as soon as it 
became available again, all hell would break loose as portage would see 
the ebuild in the overlay and try to use dynamic deps, breaking due to 
the eclasses no longer having the required support at all!

Just in case someone missed the disclaimer above, that's as I understand 
it.  I /think/ I get it, but I don't claim to be a PM/PMS expert and it's 
possible I have it wrong.

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