Re: Deleting uncompressed Info/Doc files at upgrades
On Mon, Oct 19, 1998 at 10:47:25PM -0700, Chris Waters wrote:
> 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.)
I tend to agree with you on this.
I look at it this way:
dpkg is the package manager. It is responsable for managing files in the
filesystem. It replaces files when the package calls for it, it deletes old
files.
If I edit poff (which I have) then I update ppp to the latest version,
should I expect my poff to not be replaced with the new version in
the package?
why should this NOT be so for entire directory trees?
Allowing the user/administrator to change things/save files etc is
exactly why we have /usr/local /home (and a couple of others now?)
and dpkg doesn't even try to touch them.
If you plan on changing ANYTHING in /usr/* (not local) /bin (etc) then
you should be prepared to loose whatever it is you changed
the very next time you install a package.
if you have a problem with that, you are free to not use dpkg.
> > 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.
personally...I look at it this way...
/usr/doc is not a place where conffiles go, it is a place where dpkg puts
documentation...I don't see any problem with dpkg being as bold as to just
rm -rf /usr/doc/$package and then recreating and repopulating it on every
upgrade.
just like /bin...if you have a file you don't want stepped on...
put it in /usr/local or under $home
What I consider more important is this...
I think /usr/doc does need some special handling. Specifically...
in the case that I don't want a /usr/doc (ie this is a machine that I am
never going to need documentation on...and small filesystem size is the
major imperitive)
-Steve
--
/* -- Stephen Carpenter <sjc@delphi.com> --- <sjc@debian.org>------------ */
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"
Reply to: