public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: don't rely on dynamic deps
Date: Mon, 28 Jul 2014 06:59:38 +0000 (UTC)	[thread overview]
Message-ID: <pan$7a719$9eda1481$3d70abb9$ffe87f9c@cox.net> (raw)
In-Reply-To: 53D51311.1070802@gentoo.org

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



  parent reply	other threads:[~2014-07-28  7:00 UTC|newest]

Thread overview: 276+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 19:37 [gentoo-dev] don't rely on dynamic deps hasufell
2014-07-21 19:42 ` Samuli Suominen
2014-07-21 19:50   ` Ciaran McCreesh
2014-07-21 20:06     ` Samuli Suominen
2014-07-21 20:13       ` Ian Stakenvicius
2014-07-21 20:12         ` Samuli Suominen
2014-07-21 20:17       ` Ciaran McCreesh
2014-07-21 20:28   ` hasufell
2014-07-21 20:41     ` Ian Stakenvicius
2014-07-22 22:05       ` Tom Wijsman
2014-08-27 16:18         ` Jan Matejka
2014-07-21 20:49     ` Michał Górny
2014-07-21 21:01     ` Jeroen Roovers
2014-07-21 21:06       ` Ciaran McCreesh
2014-07-21 21:13         ` Jeroen Roovers
2014-07-21 21:16           ` Ciaran McCreesh
2014-07-22 22:13       ` Tom Wijsman
2014-07-22 21:11   ` Michał Górny
2014-07-22 22:22     ` Tom Wijsman
2014-07-23 13:36     ` Ciaran McCreesh
2014-07-22 21:56   ` Tom Wijsman
2014-07-25  8:36     ` Pacho Ramos
2014-07-26 12:00     ` [gentoo-dev] " Martin Vaeth
2014-07-26 13:33       ` Pacho Ramos
2014-07-21 19:53 ` [gentoo-dev] " Andreas K. Huettel
2014-07-21 19:55   ` Ciaran McCreesh
2014-07-21 21:06     ` Pacho Ramos
2014-07-21 21:15       ` Jeroen Roovers
2014-07-21 21:21         ` Ciaran McCreesh
2014-07-21 21:25           ` Michał Górny
2014-07-21 21:30             ` Maxim Kammerer
2014-07-26 12:52               ` [gentoo-dev] " Martin Vaeth
2014-07-26 12:54           ` Martin Vaeth
2014-07-26 13:00             ` Ciaran McCreesh
2014-07-26 14:57               ` Martin Vaeth
2014-07-26 15:04                 ` Ciaran McCreesh
2014-07-22  7:39       ` Martin Vaeth
2014-07-22  7:52         ` Pacho Ramos
2014-07-22  9:50         ` Alexander Berntsen
2014-07-22 13:53       ` [gentoo-dev] " Ian Stakenvicius
2014-07-22 18:40         ` [gentoo-dev] " Martin Vaeth
2014-07-22 18:50           ` Alexander Berntsen
2014-07-23  4:11             ` Martin Vaeth
2014-07-22 18:51           ` Ulrich Mueller
2014-07-22 19:10             ` Martin Vaeth
2014-07-22 19:26               ` Ulrich Mueller
2014-07-22 20:06                 ` Martin Vaeth
2014-07-22 20:40                   ` Ulrich Mueller
2014-07-22 20:51                     ` Andreas K. Huettel
2014-07-23 13:15                       ` Ian Stakenvicius
2014-07-26 11:20                         ` Martin Vaeth
2014-07-23  1:15                   ` Rich Freeman
2014-07-25  8:38                     ` Duncan
2014-07-26 11:31                     ` Martin Vaeth
2014-07-22 22:44         ` [gentoo-dev] " Tom Wijsman
2014-07-23  0:01           ` Ian Stakenvicius
2014-07-24 22:42             ` Ciaran McCreesh
2014-07-26 13:00               ` [gentoo-dev] " Martin Vaeth
2014-07-26 13:07                 ` Ciaran McCreesh
2014-07-25 14:44           ` [gentoo-dev] " Ian Stakenvicius
2014-07-25 14:59             ` Ian Stakenvicius
2014-07-25 15:09             ` hasufell
2014-07-25 15:15               ` Ciaran McCreesh
2014-07-25 15:23                 ` hasufell
2014-07-25 15:26                   ` Ciaran McCreesh
2014-07-25 15:44                     ` hasufell
2014-07-26  7:14                       ` [gentoo-dev] " Duncan
2014-07-26 12:41               ` Martin Vaeth
2014-07-26 12:49                 ` Ciaran McCreesh
2014-07-26 15:04                   ` Martin Vaeth
2014-07-26 15:09                     ` hasufell
2014-07-26 15:12                     ` Ciaran McCreesh
2014-07-27 11:42                   ` Samuli Suominen
2014-07-27 11:50                     ` hasufell
2014-07-27 12:01                       ` [gentoo-dev] Behaving productively on the list Andreas K. Huettel
2014-07-27 12:04                         ` hasufell
2014-07-27 12:07                           ` Andreas K. Huettel
2014-07-27 12:26                             ` hasufell
2014-07-27 12:06                       ` [gentoo-dev] Re: don't rely on dynamic deps Samuli Suominen
2014-07-27 12:31                         ` hasufell
2014-07-27 13:11                           ` Rich Freeman
2014-07-27 11:54                     ` "Paweł Hajdan, Jr."
2014-07-27 11:57                       ` hasufell
2014-07-27 13:20                     ` Ciaran McCreesh
2014-07-27 13:47                     ` Michał Górny
2014-07-28  6:35                       ` Samuli Suominen
2014-07-30  4:45                     ` Alexander Tsoy
2014-07-30  5:36                       ` Samuli Suominen
2014-07-30  7:22                         ` Peter Stuge
2014-07-30  7:38                         ` "Paweł Hajdan, Jr."
2014-07-30 11:18                           ` Rich Freeman
2014-07-30 11:23                             ` Ciaran McCreesh
2014-07-30 12:38                             ` Samuli Suominen
2014-08-12 21:32                               ` Tom Wijsman
2014-07-26 12:56                 ` Ulrich Mueller
2014-08-01 21:38                   ` [gentoo-dev] PMS (was: don't rely on dynamic deps) Martin Vaeth
2014-08-02  5:19                     ` [gentoo-dev] PMS Ulrich Mueller
2014-08-02  9:30                       ` [gentoo-dev] PMS Martin Vaeth
2014-07-26 12:08           ` [gentoo-dev] don't rely on dynamic deps Ulrich Mueller
2014-07-23 13:33       ` Ciaran McCreesh
2014-07-25  1:45         ` Rich Freeman
2014-07-25 15:01           ` Ciaran McCreesh
2014-07-25 15:53             ` Alexander Berntsen
2014-07-25 18:26             ` Rich Freeman
2014-07-26 13:29             ` [gentoo-dev] " Martin Vaeth
2014-07-26 13:20           ` Martin Vaeth
2014-07-25  8:53         ` [gentoo-dev] " Pacho Ramos
2014-07-26 13:36           ` [gentoo-dev] " Martin Vaeth
2014-07-26 12:32         ` Martin Vaeth
2014-07-26 12:44           ` Ciaran McCreesh
2014-07-26 13:16             ` Martin Vaeth
2014-07-26 13:20               ` Ciaran McCreesh
2014-07-26 14:46                 ` Martin Vaeth
2014-07-26 14:53                   ` hasufell
2014-07-26 14:54                   ` Ciaran McCreesh
2014-07-26 15:11                     ` Martin Vaeth
2014-07-26 15:22                       ` Ciaran McCreesh
2014-07-26 15:40                         ` Martin Vaeth
2014-07-26 15:51                           ` Ciaran McCreesh
2014-07-28 14:30                         ` Ian Stakenvicius
2014-07-28 14:43                           ` Ciaran McCreesh
2014-07-28 15:38                             ` Ian Stakenvicius
2014-07-28 19:31                               ` Martin Vaeth
2014-07-24 22:06       ` [gentoo-dev] " Michał Górny
2014-07-25  8:51         ` Pacho Ramos
2014-07-25 17:15         ` Andreas K. Huettel
2014-07-25 17:36           ` Ian Stakenvicius
2014-07-25 17:39             ` Ian Stakenvicius
2014-07-26 17:47             ` Taahir Ahmed
2014-07-26 18:21               ` Taahir Ahmed
2014-07-26 13:41         ` [gentoo-dev] " Martin Vaeth
2014-07-26 13:46           ` Ciaran McCreesh
2014-07-26 15:01             ` Martin Vaeth
2014-07-26 15:09               ` Michał Górny
2014-07-26 15:14                 ` Martin Vaeth
2014-07-21 20:56   ` [gentoo-dev] " Michał Górny
2014-07-21 21:13     ` Samuli Suominen
2014-07-21 21:22       ` Michał Górny
2014-07-21 22:52       ` William Hubbs
2014-07-22  0:36         ` hasufell
2014-07-22  9:42           ` Alexander Berntsen
2014-07-22 19:42             ` William Hubbs
2014-07-22  1:05         ` Rick "Zero_Chaos" Farina
2014-07-22  5:10           ` Samuli Suominen
2014-07-22 23:06             ` Tom Wijsman
2014-07-26  4:36               ` Patrick Lauer
2014-07-26 13:55                 ` [gentoo-dev] binpkg (was: don't rely on dynamic deps) Martin Vaeth
2014-07-26 19:18                 ` [gentoo-dev] don't rely on dynamic deps Tom Wijsman
2014-07-22 22:52         ` Tom Wijsman
2014-07-22  1:34     ` Alexandre Rostovtsev
2014-07-22 23:13       ` Tom Wijsman
2014-07-23  2:05         ` Alexandre Rostovtsev
2014-07-26 14:02           ` [gentoo-dev] " Martin Vaeth
2014-07-26 14:29             ` Michał Górny
2014-07-26 15:18               ` Martin Vaeth
2014-07-25  7:34       ` [gentoo-dev] " Michał Górny
2014-07-22 22:29   ` Tom Wijsman
2014-07-21 21:52 ` Alexander Berntsen
2014-07-22  7:25   ` "Paweł Hajdan, Jr."
2014-07-22 18:44     ` Kent Fredric
2014-07-22 18:50       ` Alexander Berntsen
2014-07-22 23:28         ` Tom Wijsman
2014-07-23  8:53       ` [gentoo-dev] " Duncan
2014-07-26 14:12       ` Martin Vaeth
2014-07-26 22:43         ` Kent Fredric
2014-07-27  7:16           ` Martin Vaeth
2014-07-27 10:16             ` [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps) Ulrich Mueller
2014-07-27 12:19               ` Rich Freeman
2014-07-27 13:45               ` [gentoo-dev] Avoiding rebuilds hasufell
2014-07-28  5:49                 ` [gentoo-dev] " Martin Vaeth
2014-07-28 15:15                   ` Brian Dolbec
2014-08-01  9:35                   ` Steven J. Long
2014-08-01 20:49                     ` Martin Vaeth
2014-08-02 13:19                       ` Steven J. Long
2014-08-03 15:14                         ` Martin Vaeth
2014-07-27 10:43             ` [gentoo-dev] Re: don't rely on dynamic deps Kent Fredric
2014-07-27 12:04               ` Rich Freeman
2014-07-27 21:46                 ` Rich Freeman
2014-07-27 21:57                   ` Kent Fredric
2014-07-28 18:27                 ` Ian Stakenvicius
2014-07-28 18:35                   ` Rich Freeman
2014-07-22 19:05     ` [gentoo-dev] " Samuli Suominen
2014-07-22 23:32       ` Tom Wijsman
2014-07-23  1:21       ` hasufell
2014-07-23 13:34       ` Ciaran McCreesh
2014-07-22 19:26     ` Michał Górny
2014-07-22 23:21     ` Tom Wijsman
2014-07-26 12:19       ` [gentoo-dev] " Martin Vaeth
2014-07-22  8:21   ` Michael Palimaka
2014-07-22  8:32     ` Kristian Fiskerstrand
2014-07-22  9:25       ` Pacho Ramos
2014-07-22 17:03         ` Sven Vermeulen
2014-07-22 17:11           ` Ciaran McCreesh
2014-07-22 17:32             ` Samuli Suominen
2014-07-22  8:33     ` Samuli Suominen
2014-07-22 23:36     ` Tom Wijsman
2014-07-23 12:14       ` Michael Palimaka
2014-07-25 21:59         ` Tom Wijsman
2014-07-26 17:12           ` Michael Palimaka
2014-07-26 19:21             ` Tom Wijsman
2014-07-26 19:30               ` Michael Palimaka
2014-08-12 21:49                 ` Tom Wijsman
2014-07-26 14:25       ` Martin Vaeth
2014-08-12 22:11         ` Tom Wijsman
2014-07-22 11:58   ` [gentoo-dev] " hasufell
2014-07-26 14:09   ` [gentoo-dev] " Martin Vaeth
2014-07-26 14:22     ` Ciaran McCreesh
2014-07-26 14:33       ` Martin Vaeth
2014-07-26 14:36         ` Ciaran McCreesh
2014-07-26 14:40           ` hasufell
2014-07-27  7:46             ` Martin Vaeth
2014-07-26 14:32     ` Michał Górny
2014-07-26 15:27       ` Martin Vaeth
2014-07-26 15:29         ` hasufell
2014-07-26 16:10           ` Martin Vaeth
2014-07-26 15:35         ` Michał Górny
2014-07-26 15:59           ` Martin Vaeth
2014-07-26 16:02             ` Ciaran McCreesh
2014-07-26 16:36               ` Rich Freeman
2014-07-26 16:45                 ` Ciaran McCreesh
2014-07-26 15:39         ` Ciaran McCreesh
2014-07-26 16:05           ` Martin Vaeth
2014-07-26 16:14             ` Ciaran McCreesh
2014-07-26 16:28               ` Rich Freeman
2014-07-26 16:34                 ` Ciaran McCreesh
2014-07-26 18:36               ` Martin Vaeth
2014-07-26 18:42                 ` Ciaran McCreesh
2014-07-27 16:27                   ` Peter Stuge
2014-07-27 14:05   ` [gentoo-dev] " "Paweł Hajdan, Jr."
2014-07-27 14:42     ` Rich Freeman
2014-07-27 14:56       ` "Paweł Hajdan, Jr."
2014-07-27 14:59         ` Ciaran McCreesh
2014-07-27 15:09           ` Rich Freeman
2014-07-27 15:16             ` Ciaran McCreesh
2014-07-27 17:02               ` Peter Stuge
2014-07-27 17:11                 ` Ciaran McCreesh
2014-07-27 17:16                   ` Peter Stuge
2014-07-27 17:24                     ` Ciaran McCreesh
2014-07-28  6:59         ` Duncan [this message]
2014-07-28  8:26           ` [gentoo-dev] " Martin Vaeth
2014-07-28  9:28             ` Peter Stuge
2014-07-28 13:12               ` Martin Vaeth
2014-07-28 13:29                 ` Peter Stuge
2014-07-28 18:50                   ` Martin Vaeth
2014-07-28 18:57                     ` Rich Freeman
2014-07-29  7:33                       ` Peter Stuge
2014-07-29  9:12                         ` Kent Fredric
2014-07-29 10:20                         ` Martin Vaeth
2014-07-29 10:47                         ` Rich Freeman
2014-07-27 15:44       ` [gentoo-dev] " Kent Fredric
2014-07-27 15:52         ` Rich Freeman
2014-07-27 16:05           ` Kent Fredric
2014-07-28  4:43             ` [gentoo-dev] " Martin Vaeth
2014-07-27 20:24       ` [gentoo-dev] " Michał Górny
2014-07-27 20:51         ` Peter Stuge
2014-07-27 20:56           ` Ciaran McCreesh
2014-07-27 21:27             ` Kent Fredric
2014-07-27 21:34               ` Rich Freeman
2014-07-27 21:50                 ` Kent Fredric
2014-07-27 21:54                   ` Rich Freeman
2014-07-27 21:14           ` Michał Górny
2014-07-27 21:08         ` Rich Freeman
2014-07-27 21:17           ` Michał Górny
2014-07-27 21:26             ` Rich Freeman
2014-07-27 21:33               ` Ciaran McCreesh
2014-07-27 21:39                 ` Rich Freeman
2014-07-28  5:21                   ` [gentoo-dev] " Martin Vaeth
2014-07-27 22:06                 ` [gentoo-dev] " Arfrever Frehtes Taifersar Arahesis
2014-07-28 16:29           ` Ian Stakenvicius
2014-07-28 16:44             ` Rich Freeman
2014-07-28  5:06         ` [gentoo-dev] " Martin Vaeth
2014-07-27 14:42     ` [gentoo-dev] " Michał Górny
2014-07-22 21:47 ` Tom Wijsman
2014-07-25  5:44   ` [gentoo-dev] " Duncan
2014-07-25 22:09     ` Tom Wijsman
2014-07-26  5:21       ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$7a719$9eda1481$3d70abb9$ffe87f9c@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox