Re: need input: essential packages and pre-depends
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 20 Mar 1998, Ian Jackson wrote:
> Santiago Vila writes ("Re: need input: essential packages and pre-depends"):
> ...
> > For example, if diff is essential, it should Pre-Depends on libc6, because
> > otherwise maintainer scripts which use it would fail. Right?
>
> Yes. But if diff3 uses a different library, that wouldn't need a
> Pre-Depends. (We should document what commands/features you may use
> from from an Essential package.)
Ok, diff just depends on libc6, so in this case perhaps there would be
nothing to document. Or perhaps in such case it would be wise to have
diff3 in another separate package to avoid confusion (diff-nonessential).
Instead of talking about theory, I think it will be better to be
practical. Here is the (automatically generated) list of essential
packages having (still) a "Depends:" line:
1 bsdutils Depends: libc6, sysvinit (>= 2.59-2), shellutils (>= 1.15-3)
2 base-passwd Depends: libc6
3 ncurses-bin Depends: libc6, ncurses3.4
4 gzip Depends: debianutils (>= 1.6)
5 base-files Depends: awk
6 e2fsprogs Depends: comerr2g, e2fslibsg, libc6, ss2g
7 sysvinit Depends: dpkg (>= 1.4.0.21)
8 diff Depends: libc6
I will comment on each one:
1. bsdutils is essential because it contains /bin/kill.
Therefore it should probably Pre-Depends: libc6, we don't want the kill
command to stop working in the middle of an upgrade, do we?
** I will submit a bug against this if nobody objects.
I don't know the reason for the other dependencies:
sysvinit (>= 2.59-2), shellutils (>= 1.15-3)
sysvinit changelog says nothing about 2.59, but shellutils 1.15-3 replaced
bsdutils' chroot with the GNU version. Mmm, is really a Dependency what we
need here?
2. I think it is ok that base-passwd does not Pre-Depends on libc6 if it
does not run update-passwd in the postinst.
3. ncurses-bin contains "clear" and "reset", among others. If this
package is essential, then those commands are allowed to be used in
maintainer scripts. So either we keep this package essential
and put Pre-Depends: for both libc6 and ncurses3.4, or we downgrade it to
just Required but not Essential, but in such case, someone should
scan the entire set of maintainer scripts of all current packages to be
sure that no program in this package is ever used without a Pre-Depends
on ncurses-bin.
I think this is a bad time to change the essential status of a package.
** I will submit a bug against this if nobody objects.
4. gzip Depends on debianutils becaue gzexe uses tempfile.
So either we forbid the use of gzexe in maintainer scripts, or
we make gzip to Pre-Depend on debianutils.
I think it is ok to keep it as it is, but this should be documented
somewhere (that gzexe should not be used).
5. base-files Depends on awk because we wanted to make awk "essential".
Since awk may be any of mawk or gawk, and they may be used in
maintainer scripts, then both of them should have a Pre-Depends on
libc6.
** I will submit a bug against mawk and gawk if nobody objects.
6. I reported this already, because e2fsprogs had already Pre-Depends
fields in Debian 1.3.1 and they were lost in the split.
This package is being rewritten, so there is nothing to comment on it.
7. sysvinit's changelog says: "Depends on new dpkg for the new
update-rc.d" Well, if this is a simple Depends, then we can install
sysvinit without upgrading dpkg, and dpkg would not even complain. Bad
thing. Are we sure we want this? I don't think so.
** I will submit a bug against this package if nobody objects.
8. We allow diff to be used in maintainer scripts, right? If not, this
should not be essential. If yes, we would need a Pre-Depends. I think
this is not a good time to downgrade the essential flag of a package that
has been always essential. Therefore if nobody objects,
** I will submit a bug against this package if nobody objects.
I also think that some other packages would benefit from having a
Pre-Depends, for example: do we want deliver or procmail (MDAs) to fail in
the middle of an upgrade? Do we want a listserver to fail in the middle of
an upgrade. Do we want a MTA to fail in the middle of an upgrade.
Should not we make deliver, procmail, sendmail, smail, exim, smartlist,
majordomo, etc. to Pre-Depend on libc6 also?
[ Remember that we have told our users they do not need to put the machine
in single user mode... ]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNRKrEiqK7IlOjMLFAQEeJgQAnKuYVCeAwsSKdEaUaIMydQ16a5rkxr0g
ZQlxA/etd8tRAoJwnaUH0ggLeiFNnKk6c/2AjEtLMBHbCqfyeDUvpV7mj6TjZmue
KPOW2CxTGg9RR1ym42wNDnxbt5xkt/MU1pGzWAhp9jPj4T5fcyso/JIIPz1gj0AE
RV/I3opzFXI=
=Bglx
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: