Hi! The context is that Andrey wanted to get, in a maintscript, the new version of the package during upgrade, to be able to abort on downgrades, w/o needing to use a template maintscript to replace the current version at build-time, which is inconvenient.
On Wed, 2015-01-07 at 17:55:36 +0200, Andrey Utkin wrote: > 2015-01-07 17:32 GMT+02:00 Guillem Jover <guil...@debian.org>: > > Well as mentioned above you (almost?) never need to know the new > > version, only the old one. What would you need to do only on all > > downgrades, that you would not do also on all upgrades? > > > > I guess I'm not seeing the use here. > > We change database schema from time to time. We do this with scripts, > in a way similar to dbconfig-common (but it turned out to be buggy so > we made our solution from scratch). It is too hard to support > downgrading, so we need to avoid that. Ah! Ok, yes, that does make sense. So the rest of the maintainer script actions either already get the new-version, it is irrelevant, or they are passed the old-version after the new-version is already in the dpkg database which then can be retrieved through dpkg-query for example. The only problematic actions seem to be the ones involved in upgrades which only get the old-version, when it's too early for the maintscript to be able to infer the new-version by itself. So I think it would be nice to pass that as well just after old-version. Something like these changes: * postrm # After the package was upgraded: # <old-postrm> upgrade <new-version> # if that fails: # <new-postrm> failed-upgrade <old-version> # If preinst fails during upgrade of removed package: # <new-postrm> abort-install <old-version> # # If preinst fails during upgrade: # <new-postrm> abort-upgrade <old-version> Change failed-upgrade and abort-* to: # if that fails: # <new-postrm> failed-upgrade <old-version> <new-version> # If preinst fails during upgrade of removed package: # <new-postrm> abort-install <old-version> <new-version> # # If preinst fails during upgrade: # <new-postrm> abort-upgrade <old-version> <new-version> * preinst # Before removed package is upgraded: # <new-preinst> install <old-version> # # Before the package is upgraded: # <new-preinst> upgrade <old-version> Change these to: # Before removed package is upgraded: # <new-preinst> install <old-version> <new-version> # # Before the package is upgraded: # <new-preinst> upgrade <old-version> <new-version> * prerm # Before an upgrade: # <old-prerm> upgrade <new-version> # if that fails: # <new-prerm> failed-upgrade <old-version> Change failed-upgrade to: # if that fails: # <new-prerm> failed-upgrade <old-version> <new-version> The «<new-preinst> install» case (which I've ignored here) has the problem that it cannot get just the <new-version> as it would be confused with «<new-preinst> install <old-version>», but maybe that calls for passing those as envvars instead, hmmm. Of course the problem is that only new dpkg versions will pass those arguments, so its usage cannot be relied upon until after a stable release cycle anyway. I'll ponder about adding this for 1.18.x, but I'm running it through the policy list in case someone has comments or concerns. While at it, it might also make sense to pass <old-version> to: # After the package was purged: # <postrm> purge otherwise the maintscript has not way of knowing which version was purged, as the package is not in the database anymore. (Although I cannot come up right now with a situation where that might be useful? But I've not thought hard about it, and having the information allows for people to use it.) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150108191200.gb7...@gaara.hadrons.org
