Jonathan Nieder wrote: > However it is implemented, the rule should be: > > When it is time for a transitional package to go, it is removed just > as though the user specified "dpkg --remote $pkgname". Yes.
> What is a transitional package and when is its time to go is > complicated issue. Currently, yes. If we add a special section/control field/whatever else, it does not. Front-end will do all the upgrade then see what packages which was upgraded are transitional and do removal of them. [...] Removing the > transitional package as early as dependencies allow can simplify > dependency resolution for other packages in the same run Hmm, I failed to imagine a scenario for simplification. Do you have an example? >> Failed maintainer script results or in upgrade stop > [...] >> or dpkg managers to call other maintainer scripts as a fallback, they succeed >> (if they not, upgrade stops too) and upgrade continues. > > I used to think of it that way, but AFAICT I was confused. > > Example: > > Suppose I want to upgrade packages a, b, and c to a new version with > Depends: bash (>= 5). Upgrading bash to version 5 fails (in preinst, > say), so dpkg aborts the bash upgrade (bash 4.1 postinst succeeds). > Now what? Upgrade stops, bash maintainer receives a pair of grave bugs :) What else can we do? > What I meant is it could ask the user instead of starting over. In > some special cases (automatic build machine capable of diagnosing and > solving problems such as lack of free space?) something smarter might > be possible. I don't see much difference with 'upgrade stops, smart AI resolves the problems and calls the same front-end command'. Front-end will figure that some of packages are already upgraded and will schedule the actions to continue the plan. Or even different front-end/dpkg commands can be done by -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc05a37.6040...@gmail.com
