Bug#215549: Why should the postinst care if it is being confiugured or reconfigured?
Hi,
A postinst may be called with the following arguments:
* <postinst> `configure' <most-recently-configured-version>
There are three sub-cases:
1) there is no second argument -- ancient dpkg, not
relevant these days
2) the second argument is "" or "<unknown>", fresh
install.
3) The second argument is the version on the system. Either
an upgrade, or a reconfiguration
* <old-postinst> `abort-upgrade' <new version>
* <conflictor's-postinst> `abort-remove' `in-favour' <package> <new-version>
* <deconfigured's-postinst> `abort-deconfigure' `in-favour'
<failed-install-package> <version> `removing' <conflicting-package>
<version>
The question is, why should we change something so deeply
deployed as package postinst API without compelling reasons that the
postinst should treat an upgrade differently from a reconfigure,
especially since the user interaction part is already correctly
handled by debconf?
Given that we have survived for 15 years or so without postinsts
needing to make that distinction will make the compelling reason pretty
interesting.
Almost all postinsts now (and the majority of those that my
packages have) will just ignore and do nothing when called with an
unknown argument; so we can't just start passing that argument to the
postinst until almost all postinsts have been changed. It would help if
there was an easy way for lintian to check whether a postinst handles
that argument, but I can see no easy way for doing so even on my own
packages (perl, and shell postinst are the only ones I use).
Given that we will need lintian changes, a transtion plan, and a
whole lot of churn, and so far, I have seen little (and I did read
debconf-devel(7)) that offers a compelling reason to go through this
whole mess.
What am I missing?
manoj
--
Support Bingo, keep Grandma off the streets.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: