[ dropped debian-dpkg, since the question is on the level higher, as
Jonathan IIRC pointed already in threads on debian-dpkg@ ]
Hi Jonathan, John and Sara,
On 2011-07-09 20:12, John D. Hendrickson and Sara Darnell wrote:
[...] 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.
That's possible to implement in Cupt. I'm however not very
enthusiastic to do it.
Mainly, I don't think this is the only problem
with the upgrades skipping a release -- what about skipped important
maintainer scripts? And skipped transitions through package renames?
Secondly, non-pure Debian systems with third-party packages, which also
have their archives/release. In this case it's not possible to specify
one 'base release'.
Thirdly, every additional constraint in dependencies makes it harder to
generate good/safe upgrade sequences.
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?
I will probably accept a patch doing that change given it's fully
optional, not adding too much code and is isolated (i.e. ideally, patch
adds a optional function call(s) somewhere in
__fill_graph_dependencies() and __fill_action_dependencies() in
lib/src/internal/worker/packages.cpp. There should look anyone who would
want to implement this feature on the base of libcupt.
I am not sure it's worth to implement.
Regarding John and Sara's proof of concept -- as I understand this was a
pair of scripts -- one Makefile and second shell one. I have to say I
don't understand anything what's going on there, especially the end of
Makefile is write-only language to me. I can only ask if that system
works for Essential/pseudo-Essential packages and cyclic dependencies
as their handling can be tricky. Also I didn't see any handling of
Conflicts/Breaks, maybe I missed something.
Now, moving to some John and Sara's...
But this is serious. /var/lib/dpkg/available clearly shows debian
I don't think you should use /var/lib/dpkg/available as a repository. I
am not sure does it serve any real purpose these days, for example on my
system it show ~1600 package names while in the Debian repository there
are over 35000.
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 :)
Err, this is a hard statement. I don't quite understand the reasoning,
but if you think you find a grave bug in Debian's policy/dpkg/apt you
should bring this to maintainers of relevant packages.
Let me read cupt before sticking my foot in my mouth, I haven't yet :)
For what concerns your proposal, Cupt's algorithm to generate a package
changes order is much different to libapt's one. It may work better or
worse regarding your use case. I had never tried it for upgrades
skipping release.