Your message dated Tue, 12 Jul 2011 18:09:54 -0500
with message-id <20110712230954.GB16223@elie>
and subject line Re: cupt: please handle upgrades skipping a release better
has caused the Debian Bug report #633388,
regarding cupt: please handle upgrades skipping a release better
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
633388: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633388
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cupt
Version: 2.1.1
Severity: wishlist
Hi,
The following report is distilled from several messages from John
Hendrickson.
Sometimes he likes to upgrade the whole system straight from Debian
release N to N+4 or so. Yes, I know that's not supported. Yes, a
better fix would be to teach package managers or a wrapper tool the
constraint "the only supported upgrade paths are stable->anything and
release N to release N+1" so you could list them all in sources.list
and watch the Right Thing happen. But let's consider the possibility
that someone wants to do an upgrade like this where dependency
information is unreliable; can we help such a person?
John's answer is "yes". The heuristic, roughly speaking, is this:
When package A declares that it depends on B, upgrade B
before A (even if the dependency is already satisfied).
In other words, reinterpret
Depends: B
to mean
Depends: B (>= target version)
when possible.
A heuristic that is easier to justify might be to allow people to
declare which release is the predecessor release for each sources.list
entry (this includes the above as a special case: if you only have the
CD for one release at hand, you might set a release as its own
predecessor) and to reinterpret
Depends: B
to mean
Depends: B (>= version in predecessor release)
He made a prototype using tsort to order the packages being upgraded
and (iiuc) it worked ok. What do you think? Is this worth
implementing as a (perhaps optional) feature in cupt? Any advice for
future readers who might want to work on that?
John said lots of other things, but I do not have the time to read it
carefully. You can find a discussion at [*] if interested.
[*] http://lists.debian.org/debian-dpkg/2011/07/threads.html#00002
--- End Message ---
--- Begin Message ---
John D. Hendrickson wrote:
> Jonathan Nieder wrote:
>> But you can use http://archive.debian.org/, no?
>
> :) funny. but hey! I cna't access my government without an updated web
> browser.
I'm back to not having a clue what you're talking about.
Back on topic, it looks like Eugene thinks this feature request could
be interesting but it's problematic in many ways and neither he nor I
is likely to implement it. I think a more productive angle would be a
separate tool to set up sources.list, call "apt-get update" and
"apt-get dist-upgrade", and set up sources.list again in a loop.
Another nice thing to do would be to document explicitly in
debian-policy (instead of just the release-notes) that upgrades
"skipping a Debian release" are not something packages need to support
(in particular, upgrades from oldstable to sid are not supposed to
work).
Anyway, I'm closing this bug. Thanks for the food for thought.
--- End Message ---
