[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#633388: cupt: please handle upgrades skipping a release better D

Jonathan Nieder wrote:
Package: cupt
Version: 2.1.1
Severity: wishlist


The following report is distilled from several messages from John

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

Thanks Jonathan Nieder very much for taking a look.  I much appreciate it.

I think we are saying the same thing near as possible.

(It was more "if A says it depends on B but B doesn't depend on A, why try A first ? try B first then A without B if it fails")

I will read about cupt I've not seen it before.  Let me read it a bit before I speak any further :)

"because debian's notation is mathematically loose about what depends means and also breaks the math meaning and the lima given in the dictionary too, let's do A before B even though most everyone is thinking B before A works better"

I'm not being serious :)

But this is serious. /var/lib/dpkg/available clearly shows debian apt / dpkg themselves use Depends where the SHOULD have used Pre-depends (ex, libc6). That would mean we should, by debian policy, orphan apt and dpkg for insisting to use the current policy incorrectly :)

(that's more a problem concerning me: despite "who says what" there are dependencies that matter and can be found, according to maintainer advice of course)


Let me read cupt before sticking my foot in my mouth, I haven't yet :)

Thanks,  John

Reply to: