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

Re: Deleting uncompressed Info/Doc files at upgrades


	It is hard to determine the right thing to do algorithmically,
 in this case. And the primary directive should be "First, do no harm"
 files deleted are gone forever, files left around can be cleaned up
 at will.

	Create a crontab that checks for the date on a .gz file and an
 uncompressed file, and recreate the uncompressed file as needed. I
 did that for a mirror of gzipped HTML files (zcatted the newly
 mirrored .html.gz files)

	There are solutions to work around the few cases where people
 tend to uncompress sompresssed files. Ask and people can write
 scripts (pretty darn simple shelll scripts at that).

	Not everything belongs in dpkg.

>>"Peter" == Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

 Peter> Manoj Srivastava wrote:

 >> b) Package A has FILE.bz2. I put in FILE. I remove FILE.bz2. Does
 >> removing Package A remove FILE?

 Peter> I'd say yes.

	Then dpkg has just removed a file that it did not install, was
 not derived from a file dpkg installed, and it happened even when a
 user did not muck with the files dpkg installed. I would be most
 annoyed at losing that file.

 >> c) Package A has FILE.bz2. Package B has FILE.gz. Should these conflict?

 Peter> Does that occur in slink?  I'd be surprised.

	Current instances shuld not be all that packages should be
 desgned for. This may happen in the future, and dpkg should be

 Peter> Is there is single case of /usr/doc/packagename/file coexisting with
 Peter> either /usr/doc/packagename/file.{bz2,gz} ?

	Not yet. However, that can be changed. just give me tie to
 upload a package ;-)

 Peter> We already know that _all_ info file are shipped compressed, so
 Peter> uncompressing them should lead to _no_ ambiguity.

	dpkg does not knwo an info file from a /sbin file. I see no
 good coming out of making dpkg aware of file contents (huge
 bureaucratic nightmare)

 >> d) Package A has FILE.bz2. When upgrading the package, should FILE
 >> disappear? 

 Peter> I'd say yes.

	Even when FILE.bz2 exists? Again, dpkg has exceeded its
 authority by removing files that did not belong to any package.

 Peter> I suppose by "win", I ultimately meant to convince people that
 Peter> it's a good idea such that someone (anyone) implements it to
 Peter> make Debian better for all of us.  I wasn't pleading for
 Peter> someone to spend hours coding something for noone to use but
 Peter> me (although I've been known to do that _for_ others), I was
 Peter> suggesting something which I thought would make Debian better.
 Peter> I hope that's allowed in this forum, and even possibly
 Peter> encouraged.

	I would not have put it in such a zero sum game manner,
 but.... I, for one, am not convinced, for what that counts. Not that
 it really counts for much, since Ian and Klee are the people in

 Peter> I don't code in C yet, so it's not likely going to be me doing
 Peter> the coding.  If that means I should keep my ideas for myself,
 Peter> please let me know and I will do so forever (wrt
 Peter> debian-devel).

	Nope, ideas are alwayes welcome (the only time I objected to
 someone was when they demanded change, and turned abusive when
 thwarted). As you are aware, unless you do the coding, you have to
 convince the authors (Ian and Klee, in this case)

 "Marriage is low down, but you spend the rest of your life paying for
 it." Baskins
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Reply to: