Re: Deleting uncompressed Info/Doc files at upgrades
Hi,
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
prepared.
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
charge.
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)
manoj
--
"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: