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