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

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

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

	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.


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 new users.

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)

Reply to: