Re: Policy rewrite: chaps 7-10
Previously Julian Gilbey wrote:
> 7.2 Binary dependencies
> This section states that "All but Pre-Depends and Conflicts take
> effect only when a package is to be configured." But actually,
> dpkg appears to ignore everything except for (Pre-)Depends,
> (sometimes) Recommends and Conflicts. So what should this say?
It should say what it currently says.
> 7.2 Depends: should also mention "or if it is required by the
> postinst, prerm or postrm scripts".
Remove postrm from there, that can't rely on the Depends being present.
> 7.5 States:
> Virtual packages (Section 7.4, `Virtual packages - `Provides'') are
> not considered when looking at a `Replaces' field - the packages
> declared as being replaced must be mentioned by their real names.
> But does it in a Provides/Conflicts/Replaces scenario, as
> described in 7.5.2?
P/C/R is really a special case.
> 7.5.1 States:
> In the future `dpkg' will discard files which would overwrite those
> from an already installed package which declares that it replaces the
> package being installed. This is so that you can install an older
> version of a package without problems.
> Has this now happened?
What do you mean? This has always been true.
>
> Chapter 9
> Should mention that ld.so might actually be ld-linux.so or
> something else instead.
It could be anything basically, especially if you start thinking about
Debian GNU/HURD or BSD versions.
> 9.2.2 Should say what dpkg-shlibdeps actually does if we're going to
> say anything at all.
The footnote should be zapped and the merged into the real text. What
it says won't be entirely correct either once I replace dpkg-shlibdeps
with the python versions.
> 9.2.* Do we need /etc/dpkg/shlibs.default any longer?
Yes.
> 10.1.2: Surely directories should be removed by postrm, not prerm?
> (Prerm may not always be called, eg if a package disappears.)
Either might happen.
10.3.1: needs to be rewritten for LSB complience which defines
specific runlevels.
> 10.3.2: Hard question:
> Not all of start, stop, restart etc. are relevant for everything
> in /etc/init.d, for example checkfs.sh. We should figure out a
> way of distinguishing between daemons (which should accept all of
> these) and specific startup/shutdown scripts (which needn't).
Daemon or non-daemon is a really bad measure.
> 10.3.2: Should "The start, stop, restart and force-reload options
> should be supported" be replaced by "must be supported",
> contingent on the above suggestion?
I don't think force-relead must be supported, restart already does
the same thing. The other three should be a must though.
Wichert.
--
________________________________________________________________
/ Generally uninteresting signature - ignore at your convenience \
| wichert@cistron.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: