On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote: > > Does dpkg provide any guarantee that the dependencies of the > > pre-dependency are also present at this point? If it doesn't, I think > > that should be considered a bug in dpkg, since you may be invoking a > > command that links against a library whose soname has changed since the > > last time the pre-dep package was configured. If it /does/ provide this > > guarantee, I think it should be documented in Policy.
> I believe they can be in the same state as the pre-dependency itself for > exactly the same reasons, no? Upgrades don't require deconfiguring > packages that depend on the package being upgraded, so if you abort in the > middle of upgrading a package the pre-dependency depends on, the > pre-dependency is still present and configured on the system, so dpkg will > treat the pre-dependency as satisfied. The question is, if you upgrade a package which is a pre-dependency of another package, are any *new* dependencies of that package guaranteed to be unpacked before the package itself is? This seems like a sensible thing for the package manager to enforce, but I don't know if anything does so in practice. > >> + unpacked in some error situations.<footnote> > >> + For example, suppose packages foo and bar are installed > >> + with foo depending on bar. If an upgrade of bar were > >> + started and then aborted, and then an attempt to remove > >> + foo failed because its <prgn>prerm</prgn> script failed, > >> + foo's <tt>postinst abort-remove</tt> would be called with > >> + bar only "Half-Installed". > >> + </footnote> > >> </item> > >> - </list> > >> + </taglist> > >> + </p> > > This footnote is interesting to me because although it accurately > > documents dpkg's behavior, I'm not sure what implications it has for how > > packages should guard against this case. I think I've always ignored > > this possibility in my maintainer scripts, and will continue to do so on > > the grounds that any attempt to handle this gracefully is likely to > > introduce much greater complexity (and therefore bugs) with very little > > upside (when all is said and done, a package you were trying to remove > > is still installed, so do we care if it configures successfully?) > > If we can make a straightforward recommendation to maintainers for how > > to handle this case, I think we should include that in the footnote. > > Otherwise, if it shouldn't affect how we write maintainer scripts, > > perhaps it's better not to have this footnote at all since it would only > > lead to maintainers trying to be too clever and shooting themselves in > > the foot? > I think we should put it in the main text. I've now added, after the > footnote and in the main text: > The <prgn>postinst</prgn> should still attempt any actions > for which its dependencies are required, since they will > normally be available, but consider the correct error > handling approach if those actions fail. Aborting > the <prgn>postinst</prgn> action if commands or facilities > from the package dependencies are not available is often the > best approach. > which I think is roughly what you're doing and what most people are doing > and which I think is the generally best approach. Sounds good to me, thanks. > >> <p> > >> The <tt>Depends</tt> field should also be used if the > >> - <prgn>postinst</prgn>, <prgn>prerm</prgn> or > >> - <prgn>postrm</prgn> scripts require the package to be > >> - present in order to run. Note, however, that the > >> - <prgn>postrm</prgn> cannot rely on any non-essential > >> - packages to be present during the <tt>purge</tt> > >> - phase. > >> + <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts > >> + require the depended-on package to be unpacked or > >> + configured in order to run. In the case of <tt>postinst > >> + configure</tt>, the depended-on packages will be unpacked > >> + and configured first. (If both packages are involved in a > >> + dependency loop, this might not work as expected; see the > >> + explanation a few paragraphs back.) In the case > >> + of <prgn>prerm</prgn> or other <prgn>postinst</prgn> > >> + actions, the package dependencies will be at least > >> + unpacked or "Half-Installed". > >> + </p> > >> </item> > > I disagree with this change. If you are making use of non-essential > > packages in your postrm, you *should* use the Depends: field; you just > > *also* have to have a clean fallback plan if the dependency is not > > satisfied when the postrm is called. > > The normal use case is "whichever of the two packages is removed first > > must clean up". While I can't think of a case where the cleanup > > interface called from the postrm isn't already a dependency for other > > reasons (e.g., for use in the postinst), I'd like this to be explicit > > all the same. > How about this? > <p> > The <tt>Depends</tt> field should also be used if the > <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts > require the depended-on package to be unpacked or > configured in order to run, or if the dependend-on package > is desirable for cleanup done by <prgn>postrm</prgn>. In > the case of <tt>postinst configure</tt>, the depended-on > packages will be unpacked and configured first. (If both > packages are involved in a dependency loop, this might not > work as expected; see the explanation a few paragraphs > back.) In the case of <prgn>prerm</prgn> or > other <prgn>postinst</prgn> actions, the package > dependencies will normally be at least unpacked, but they > may be only "Half-Installed" if a previous upgrade of the > dependency failed. In the case of <prgn>postrm</prgn>, > there are no guarantees, but the depended-on package is > more likely to be available if the package declares a > dependency (particularly for <tt>postrm remove</tt>). > The <prgn>postrm</prgn> script must cleanly skip actions > that require a dependency if that dependency isn't > available. > </p> s/desirable/wanted/? and s/dependend/depended/ :) Seems ok to me. Better than Jonathan's proposed wording, which doesn't read well because there's too much repetition. I might also add at the end: In such situations, the depended-on package should perform an equivalent clean-up operation if it's the first package to be removed or purged. But that may not be unambiguous enough to add any value here and I can't be bothered to further tune the language right now; I don't think that's a blocker and this bug has run quite long enough already. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100816005044.ga11...@dario.dodds.net
