On Thu, Mar 15, 2001 at 01:40:47PM +0100, Wichert Akkerman wrote:
> 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.
So this paragraph should only talk about these.
> > > > 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".
OK.
> > > > 7.5.1 States:
> > > > In the future `dpkg' will discard files which would overwrite
> > > > those
> > > > [...]
>
> 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.
Ah! Then very unfortunate wording here. The following should make
things clearer:
`dpkg' discards files which would overwrite those ...
> > 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.
Agreed. I presume that ldconfig exists on all systems, though.
> > > > 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.
Please explain; I don't know what you mean here.
> > > 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/).
Are we going to follow the LSB for runlevels? Is there anything else
we should be following it for? This should definitely be a separate
proposal.
> > > > 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.
But it makes no sense to force-reload or stop or restart checkfs.sh.
> If we really need to have some distiction I would use /etc/rcS.d versus
> /etc/rc[2-6].d scripts.
What about /etc/rcS.d/S40networking? Or /etc/rc[2-5].d/S99rmnologin?
These two cases show that it's pretty close, but not quite all the way
there.
> > > 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.
But should force-reload be a "must"?
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
