FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-10-2011, 12:12 AM
"John D. Hendrickson and Sara Darnell"
 
Default Bug#633388: cupt: please handle upgrades skipping a release better D

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E18EE60.7010402@cox.net">http://lists.debian.org/4E18EE60.7010402@cox.net
 
Old 07-12-2011, 08:58 AM
"John D. Hendrickson and Sara Darnell"
 
Default 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.



Hi,

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)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E1C0C99.2020106@cox.net">http://lists.debian.org/4E1C0C99.2020106@cox.net
 

Thread Tools




All times are GMT. The time now is 02:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org