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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
