Re: POSIX shell; bash ash pdksh & /bin/sh
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 5 Aug 1998, Buddha Buck wrote:
> Santiago Vila said:
> > The role of the essential flag is not to avoid breaking promises, it is to
> > avoid the user to break their system, leaving it in an unrecoverable
> > state.
> > [...]
>
> I beg to differ. If that is indeed the case, then the policy manual
> needs to be updated to reflect that.
>
> The Policy Manual version 2.4.1.2 refers to the "Essential" flag a
> number of times:
> [...]
>
> So all reference to essential packages (except for possibly sec.2.3.7)
> only refer to the fact that other packages don't have to depend on them.
Yes, because they are always on the system. But all those facts are not a
*definition* of essential but instead a set of *properties* an essential
package has when it is essential. Do not confuse the rationale for making
a package essential with the properties it has when it is essential.
> Section 2.3.7 is interesting in what it -doesn't- say:
> [...]
>
> Please note that it doesn't define what is meant by "essential". In
> essence, it uses a circular definition to define the use of the flag.
Ok, maybe the policy does not explain very well the rationale for making a
package essential. It just says essential packages are "essential to the
system".
Well, could you please then look in the debian-devel archives for
messages from Ian Jackson?
If you do that you will see that the meaning of the words "essential to
the system" is: If you remove them, the package system (or the system) breaks
in an *unrecoverable* way (not just in a recoverable way like
required-but-non-essential packages). For example, if you remove dpkg,
you will be unable to install dpkg again, since you are supposed to
install any package (including dpkg.deb) by using dpkg itself. Therefore
dpkg has to be essential.
> [...]
> As it stands, many packages have undeclared dependencies on bash. That
> seems to match perfectly with the semantics of an "essential" package.
No, the essential flag dictates the semantics, but not conversely.
We have undeclared dependencies on bash because policy says that being
bash essential we have not to declare dependencies on it.
As long as we decide that bash has not to be essential anymore, we would
have to make explicit all those implicit dependencies.
BTW: The fact that we have *many* dependencies (implicit or explicit)
is not a reason at all to make a package essential, otherwise we would
have to make libc6 essential, thing that even policy forbids.
The rationale for not making libc6 (and libraries in general) essential is
that you should be able to remove it when you need it. Exactly the same
as in the bash case. If another package provides /bin/sh, then it may be
the case that you don't need bash any longer, and therefore you should be
able to remove it (no, --force-remove-essential does not count, I mean
you should be able to remove it without any additional dpkg flag
as long as any other package depends on it).
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNcl5WSqK7IlOjMLFAQEUVgP/S4pzFZna7wfyk9uLy9XhgRhTRc2kDBeK
Clg3COxI/ZB5ZKZBPCRJmnrutuQqIWdeMzxu61DO7J1TAqRQM4d/P7603vT7GQ2O
Vndm+dEHaURmMjro+F5JrKH+CAW/CTEJvl06SKX+d1zNHTJy8ZXU3/U8p9+QE+s5
vnNxDtkjWN4=
=7LJB
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: