Re: Policy rewrite: chaps 7-10
Previously Julian Gilbey wrote:
> But what does it mean for a "suggests to take effect"?
(Pre-)Depends, Conflicts and Replaces are the only ones that dpkg
cares about, the others are for frontends like dselect. A Suggests
can't really take affect.
>
> > > 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.
>
> So we should say that somewhere; it's probably important:
> The postrm must not depend on any non-essential package.
non-essential is wrong wording, it can't rely on packages one Depends
on to be present (same Pre-Depends) while it is called for "purge".
It can rely on them being present during a "remove".
> > > 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?
> That's what the text currently says, taken straight from the old
> packaging manual, AFAIK.
Differences in interpretation, consider that the packaging manual was
never written to be a policy document. `will' here was meant to indicate
that dpkg will always do that, not that it will do that at some point
in the future.
> Agreed, so we should say something about this, perhaps only in a
> footnote.
I would rather that we remove the mention of ld.so and just say
`dynamic linker'. That is accurate and flexible. The specific filename
for the dynamic linker is an implementation detail.
> > > 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.
>
> What do you mean? Maybe I wasn't clear. The text suggests that
> directories in /usr/local must not be in the .deb, but must be created
> in the postinst and removed in the prerm; I asked why the prerm and
> not the postrm. Actually, there is a reason: the postrm may not be
> called if there's an error-unwind situation.
>
> Which is better to do: prerm, postrm or leave it up to the maintainer?
prerm so we can handle error-recovery quicker.
> > 10.3.1: needs to be rewritten for LSB complience which defines
> > specific runlevels.
>
> OK, if you can give some pointers or details, that would be good.
I would need to check, basically the LSB defines runlevels:
* single users
* multi user with network
* multi user with network and X
etc.
I don't remember the specifics from memory, but you should be able
to find those in the LSB documents (see http://www.linux-base.org/).
> > > 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.
>
> Fine. Do you have any ideas of what the measure should be? I don't.
> I just know we need one.
I don't think we need a measure. I want to be able to force-reload
my network config for example, to flush out bad firewall and routing
entries.
If we really need to have some distiction I would use /etc/rcS.d versus
/etc/rc[2-6].d scripts.
> > I don't think force-relead must be supported, restart already does
> > the same thing. The other three should be a must though.
>
> OK.
I gave this some more thought and decided that force-reload does make
sense: reloading is a very different thing from restarting, but if a
service doesn't support it we don't want to try a restart after a reload
failed. For this reason a force-reload is useful.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wichert@cistron.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: