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

["John D. Hendrickson and Sara Darnell" <johnandsara2@cox.net>]

Jonathan Nieder wrote:
> 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

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