Eugene V. Lyubimkin wrote: [reordered]
> My point is: if this exception was not exist, the things would be much > simpler. No one would try to explain why it is not here. [...] > The only benefit > - autoremoval of transitional packages - can be implemented on the front-end > side after, for example, front-end will know that this package is > transitional, so it will plan it's removal after installing its dependencies. 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". What is a transitional package and when is its time to go is complicated issue. It would be nice to include this feature even when working without a front-end, even though I understand your argument that a front-end can support the functionality better. Removing the transitional package as early as dependencies allow can simplify dependency resolution for other packages in the same run, so there is still a case for this to be understood by dpkg. dpkg itself should not treat any archive sections differently from others, so while ugly, the rules about disappearance are the best approximation I know of to the right thing for dpkg to pay attention to. > 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? All of the fallbacks for failing maintainer scripts work this way: they cancel one attempted operation and try to get into a different sane state. >> The front-end could say to continue with whatever remaining requests >> are valid, or trying configuring pkgname again, or reinstall pkgname, >> or whatever it wants to do. [...] > (what would change by the time of the second run?), and manual > intervention needed. 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. > Well, dpkg has something like this ability (--command-fd) Thanks for pointing me to it. > I would like to have libdpkg shared library instead with a > clean API to do things. Yes, I am very glad that is coming, too. Sorry for the long thread. I think I am up to speed now. Thanks, everyone. Jonathan -- 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/20100410092631.ga22...@progeny.tock
