Re: FOUND IT!!! was Re: Problems with dselect...

[Santiago Vila <sanvila@unex.es>]

On Wed, 17 Mar 1999, Ian Jackson wrote:

> Santiago Vila writes ("Re: FOUND IT!!! was Re: Problems with dselect..."):
> > A Pre-depend on an optional package is not a mistake as such (provided
> > the Pre-Depend itself is jutified enough, of course).
> 
> Perhaps this policy should be changed.  The reason for the restriction
> in the policy manual is that otherwise there can be very severe
> constraints on the order in which packages must be presented to dpkg.
>
> I'd like (at some point, anyway) to be able to install from tape
> without winding the tape back and forth too much, and without having
> to make the tape in a very special way.

What's wrong with making the tape so that all the Pre-Depends targets
are always before the packages having the Pre-Depends?

We have make the Debian 2.1 first CD-ROM to fulfill all of its
dependencies, this is not very special. We could make an "official Debian
Tape" having the Pre-Depends targets at the beginning of the tape as well,
and it would not be very special either.

> In my old version of the policy manual (from dpkg 1.4.0) I said:
>   <sect1><tt/Pre-Depends/ and the <tt/Essential/ flag
>   <p>
> 
>   Do not use <tt/Pre-Depends/ or <tt/Essential: yes/ unless your package
>   is absolutely vital to the functioning of the system and the
>   installation of other packages.  Do not do either of these things
>   without consultation with the distribution maintainers or on
>   <prgn/debian-devel/.
>   <p>
> 
>   Usually, neither of these fields should not be used unless removing a
>   package really will completely hose the system, making it impossible
>   to recover by (re)installing packages with <prgn/dpkg/.
> 
> I see that this was removed at some point.
> 
> I think it should be put back.

This is almost exactly what we currently do.

I would just change an "and" by an "or" in this phrase:

... is absolutely vital to the functioning of the system OR the
installation of other packages.

Thanks.

-- 
 "5808599b73624e46509b7bd0eb18375c" (a truly random sig)