[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 

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)


/* -- 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: