Re: Deleting uncompressed Info/Doc files at upgrades
Manoj Srivastava wrote:
> I agree with you there. dpkg, or any other program, should not
> second guess the human this way.
Excuse me? Couldn't dpkg's *entire* job be described as second guessing
the human? The tricky part is and always has been getting it right:
obvious things like, "you don't want to install that without the
libraries it requires," are easy, but it's still second guessing. This
particular case may be more complex, but it's still *just* as
appropriate for dpkg to second-guess the human *if* it can get it right.
In the case of compressed vs. uncompressed files, dpkg is already
capable of this. Just move the files in question to a separate package,
provide two versions of the package, with and without compression, and
voila!
(The disadvantage to this approach is that it's a *whole* lot more work
for the developers, and more confusing to the users with so many
packages. It's impractical, but *theoretically* possibly right now,
which knocks down your whole argument that it's philosophically wrong.)
> dpkg does not know that a file is a document, or have any idea
> of the information content of files in general, apart from maintainer
> scripts.
Nor does it need to. There is a more general idea underlying the
obvious idea that some may want compressed documentation and some may
not. And that is the basic idea that a file or set of files may come in
several different forms WITH DIFFERENT NAMES. I think that would be a
very useful abstraction for a packaging tool to support.
I think there are some useful ideas here that bear discussion. I do NOT
think these ideas deserve to be dismissed, especially with such an
obviously incorrect claim as: "dpkg shouldn't second-guess the user."
However! I also think that we should spend the time to come up with a
good, clean design, if we do this, and I don't think any of the current
proposals qualify. Wildcards are too wild, and too ambiguous; I think
what we need is a way for the user to pick one of a set of options, and
have dpkg/apt manage that option. That should address your concerns
about dpkg overstepping its bounds.
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or cwaters@systems.DHL.COM | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: