[ 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. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
