Eugene V. Lyubimkin wrote:
[ 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 (>= target version)
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
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
Yes I agree. And it is more than I though at first (I thought it would be). It is preliminary work
not [yet] meant to check ver, removes, etc. Infact the idea included that it wouldn't need to "do
it all" to help.
I'm thinking about everything everyone's mentioned. I've learned what and how is needed. I also
think about how to best apply with the time I have.
I keep saying: dpkg does go in a "right order" ... but doesn't seem to know it's gone astray
I like like the idea cupt for advanced users. I haven't read enough to know if it would also help
As to skipping releases - we can't all be continual updaters
BTW hears the head of the "make show" (sorted by pri afterward to make it look better).
28948 req 1 lib libc-bin
34890 req 1 lib gcc-4.4-base
30847 req 1 lib libc6
12555 req 1 lib libgcc1
30527 req 1 lib libselinux1
11401 req 1 lib zlib1g
16481 req 1 lib libattr1
21938 req 1 lib libacl1
24252 req 1 lib liblzma2
1168 req 1 uti coreutils
23154 req 1 uti xz-utils
25017 req 1 adm dpkg
6758 req 1 per perl-base
14447 req 1 lib libncurses5
34457 req 1 per libtext-charwidth-perl
25575 req 1 per liblocale-gettext-perl
13994 req 1 per libtext-iconv-perl
260 req 1 per libtext-wrapi18n-perl
22448 req 1 lib libslang2
16849 req 1 uti sed
6740 req 1 uti ncurses-bin
4893 req 1 uti sensible-utils
3110 req 1 mis lsb-base
1293 req 1 uti debianutils
19063 req 1 lib libcomerr2
4309 req 1 lib libpam0g
8780 req 1 adm libpam-modules
21626 req 1 adm passwd
2789 req 1 lib libuuid1
22624 req 1 lib libblkid1
8655 req 1 lib libsepol1
29463 req 1 adm sysvinit-utils
13754 req 1 adm mount
BTW no I'm not continuing with AWK. The number blocks are for importing when I get the time
(it picks pretty good order by just Depends: names if your thinking "new installs from avail.")
(I haven't tried installing in this order yet but I will try it on a machine)
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org