Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On Mon, Sep 03, 2001 at 06:52:55PM +1000, Herbert Xu wrote:
> Steve M. Robbins <steven.robbins@videotron.ca> wrote:
>
> > --- policy.sgml.orig Sun Sep 2 22:50:21 2001
> > +++ policy.sgml Sun Sep 2 22:52:26 2001
> > @@ -3718,7 +3718,7 @@
> > </p>
> >
> > <p>
> > - However, <prgn>postrm</prgn> and <prgn>preinst</prgn> scripts
> > + However, <prgn>postrm</prgn> and <prgn>postinst</prgn> scripts
> > <em>must not</em> call <prgn>ldconfig</prgn> in the case where
> > the package is being upgraded (see <ref id="unpackphase"> for
> > details), as <prgn>ldconfig</prgn> will see the temporary
>
> Objection. There's nothing wrong with calling ldconfig in the postinst
> durinag an upgrade.
Indeed, you are correct. That deepens the mystery of what this
paragraph is supposed to mean, because it is equally true that there
is no problem in calling preinst during an upgrade.
The issue is to avoid calling "ldconfig" when a temporary copy of
a shared lib exists on-disk. In section 6.5, the following scripts
are (possibly) invoked during this critical phase:
old-postrm upgrade new-version
new-postrm failed-upgrade old-version
old-preinst abort-upgrade new-version
disappearers-postrm disappear overwriter overwriter-version
Perhaps the intention of the section 9 paragraph (above) was to
say
However, the postrm script must not call ldconfig if invoked
with the argument "upgrade", "failed-upgrade", or "disappear".
The preinst script must not call ldconfig if invoked with
the argument "abort-upgrade".
However, that is a bit longwinded and fairly confusing.
As far as I can see, the correct times to call "ldconfig" are
precisely: (a) in "postinst configure" and (b) in "postrm remove".
Situation (a) handles the case of a new or upgraded lib, and (b)
handles the case when the shared lib vanishes for good. Indeed, these
two calls are exactly what the dh_makeshlibs will insert into the
pre/post scripts when building a package.
[As a bonus, ldconfig is only called once during an upgrade since the
old-postrm is called with the argument "upgrade" rather than "remove".]
Would there be a problem with enshrining this with the following
policy simplification?
-Steve
P.S. If anyone remembers, why is it that the postinst rule is a "must",
while the postrm rule is a "should"?
--- policy.sgml.orig Sun Sep 2 22:50:21 2001
+++ policy.sgml Tue Sep 4 20:50:04 2001
@@ -3714,18 +3714,8 @@
must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
script if the first argument is <tt>configure</tt> and should
call it in the <prgn>postrm</prgn> script if the first
- argument is <tt>remove</tt>.
- </p>
-
- <p>
- However, <prgn>postrm</prgn> and <prgn>preinst</prgn> scripts
- <em>must not</em> call <prgn>ldconfig</prgn> in the case where
- the package is being upgraded (see <ref id="unpackphase"> for
- details), as <prgn>ldconfig</prgn> will see the temporary
- names that <prgn>dpkg</prgn> uses for the files while it is
- installing them and will make the shared library links point
- to them, just before <prgn>dpkg</prgn> continues the
- installation and renames the temporary files!
+ argument is <tt>remove</tt>. Apart from these two circumstances,
+ the maintainer scripts must not call <prgn>ldconfig</prgn>.
</p>
<sect>
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: