I am proposing the following patch to policy. The difference from my
previous proposal is to allow calling "ldconfig" in the "postinst" no
matter what the arguments are. Detailed rationale follows, below.
--- policy.sgml.orig Sat Sep 8 16:12:53 2001
+++ policy.sgml Sat Sep 8 17:06:01 2001
@@ -3711,21 +3711,16 @@
</list>
</p>
</footnote>
- 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!
+ must use <prgn>ldconfig</prgn> to update the shared library
+ system. The package must call <prgn>ldconfig</prgn> in the
+ <prgn>postinst</prgn> script if the first argument is
+ <tt>configure</tt>; the <prgn>postinst</prgn> script may
+ optionally invoke <prgn>ldconfig</prgn> at other times. The
+ package should call <prgn>ldconfig</prgn> in the
+ <prgn>postrm</prgn> script if the first argument is
+ <tt>remove</tt>. The maintainer scripts must not invoke
+ <prgn>ldconfig</prgn> under any circumstances other than those
+ described in this paragraph.
</p>
<sect>
On Wed, Sep 05, 2001 at 06:21:36PM +1000, Herbert Xu wrote:
> On Tue, Sep 04, 2001 at 08:53:20PM -0400, Steve M. Robbins wrote:
> > On Mon, Sep 03, 2001 at 06:52:55PM +1000, Herbert Xu wrote:
> >
> > Would there be a problem with enshrining this with the following
> > policy simplification?
>
> Nope. It still has the same problem, i.e., all packages simply doing a
> ldconfig in their postinst is now violating the policy.
This is true. It raises two questions in my mind.
1. Is it a useful thing to run "ldconfig" unconditionally in postinst?
2. How many packages would acquire bugs if we disallowed it?
After combing through the details of maintainer scripts and their
interaction described in Policy Chapter 6, I have concluded that
the answer to question 1 is "no". I'll present details below.
To answer question 2, I had a look at packages in the current pool and
counted how many bugs would be induced by the change. I ran a patched
version of lintian incorporating extra checks for shared libs (see
Bug#110465) on all the -i386.deb files of auric's pool:
find /org/ftp.debian.org/ftp/pool/main -name '*-i386.deb'
| xargs -l1 lintian --root ~/lintian/lintian-1.20.14.2 -C shared-libs
[I wanted to avoid scanning each package for each architecture. I had
intended to look at the "i386" architecture to get the largest sample,
but I see now that I goofed and only captured "hurd-i386"... I'm
re-running on *_i386 now, but I don't expect the larger sample to
change the results, so I'm sending this email now.]
The complete output in ~smr/check-libs on auric. When I did this, a
couple nights ago, there were 1991 such files. I turned up 149 that
may call "ldconfig" in the postinst without checking that the argument
is "configure". The lintian check will report any postinst script
that calls "ldconfig" without prefixing it by 'if [ "$1" = "configure"
]; then'. Scripts that use a case statement instead are thus included
in the output, meaning that the problem may be overestimated.
At any rate, 151/1991 is about 8% which is more than I had bargained
for. I therefore modified the proposed policy change, as already
described.
Now, it is true that my proposed change remains more restrictive than
strictly necessary. It forbids, for example, calling "ldconfig"
during "postrm purge". That is certainly no loss as "postrm remove"
always runs before "postrm purge". Branden Robinson, Herbert Xu, and
Steve Greenland have already indicated support for an alternative,
more conservative wording that simply forbids running "ldconfig" in
circumstances known to be harmful.
I considered this approach, but I believe the current proposal is
superior for its simplicity. It is less mental work to comprehend
you should invoke ldconfig in these 2 circumstances; you may also
do it in a third circumstance, but no others are permitted
than
you should invoke ldconfig in these 2 circumstances; you must
not invoke it in these four circumstances
In the second case, one is left wondering about cases neither mandated
nor forbidden. It is easier to write a heuristic checker for the
first formulation, for a similar reason.
I have gone through the maintainer script details described in chapter
6, with an eye to how they relate to shared libs and "ldconfig". For
each of the four scripts, I have described how they relate to invoking
"ldconfig", what the current policy is, and how it is affected by the
current proposal. Finally, I describe how many new bugs are
introduced in the sample of 1991 packages that I scanned the other
night. Only one package would be affected by this change, and in
that case, the bug is a real one.
preinst
-------
During install or upgrade, this script is called before the new files
are unpacked, so calling "ldconfig" is pointless.
The preinst of an existing package can also be called if an upgrade
fails. However, this happens during the critical time when a shared
libs may exist on-disk under a temporary name. Thus, it is dangerous
and forbidden by current policy to call "ldconfig" at this time.
Current policy disallows "ldconfig" in preinst during upgrade.
Proposed change: completely forbid "ldconfig" in preinst scripts.
Bug Impact: no new bugs created.
postinst
--------
When a package is installed or upgraded, "postinst configure" runs
after the new files are safely on-disk. At this point, current policy
is that one SHOULD run "ldconfig".
The postinst can also be called to recover from a failed upgrade.
This happens before any new files are unpacked, so there is no reason
to call "ldconfig" at this point.
Current policy mandates that "postinst configure" runs "ldconfig".
Proposed change: none.
prerm
-----
For a package that is being removed, this is called with all the files
intact, so calling ldconfig is useless.
The other calls to "prerm" happen in the case of upgrade at a time
when all the files of the old package are on-disk, so again calling
"ldconfig" is pointless.
Current policy is silent on "ldconfig" in the prerm.
Proposed change: forbid "ldconfig".
Bug Impact: induces a bug in 1 package
Incidentally, this bug (in libclips) is a real bug: the prerm script
makes the call when its arguments are "purge", but "prerm" scripts are
never called with arguments "purge" --- this bit was clearly intended
for the "postrm" script. (See also Bug #111542).
postrm
------
An installed shared lib has been removed from the system just before
"postrm remove" is run. This is the proper time to call "ldconfig"
to notify the system of that fact. Current policy has this as a
SHOULD requirement. I still haven't found out why it is not MUST.
The postrm can be called at several other times. At the time of
"postrm purge", "postrm abort-install", or "postrm abort-upgrade",
calling "ldconfig" is useless because the shared lib files are not
on-disk.
However, when "postrm" is invoked with arguments "upgrade",
"failed-upgrade", or "disappear", a shared lib may exist on-disk
under a temporary filename. Calling "ldconfig" at such time is
forbidden by current policy.
Proposed change: allow "ldconfig" only during "postrm remove"
Impact: no bugs introduced
(My lintian scanner found 2 false matches)
-Steve
--
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
