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 \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
