Re: Deleting uncompressed Info/Doc files at upgrades
Rob Browning wrote:
> Chris Waters <xtifr@dsp.net> writes:
> > What I was suggesting was that we look for more basic underlying
> > issues. Rather than focusing on the specific case of compressed vs.
> > uncompressed documentation, we should look at the basic concept of
> > files that can appear in different forms with different names. We
> > already handle this at the gross inter-package level, but it might be
> > nice to have a mechanism that can handle this within a package.
> I would suggest that a cleaner solution than the ones presented that
> would make most people happy would be the (discussed in the past)
> config file options to dpkg like:
> (set-dpkg-doc-policy! 'no-docs)
> or
> (set-dpkg-doc-policy! 'compressed) ;; The default
> or
> (set-dpkg-doc-policy! 'uncompressed)
*I* certainly wouldn't call that cleaner -- in fact, I'd refer to it as
a major hack. As Manoj has pointed out, dpkg doesn't currently know
anything about *types* of files. So you have to implement some
mechanism for classifying the files dpkg installs. Which opens up a
whole debate about classification that I for one would rather skip if at
all possible.
Don't believe for a second that this sort of problem is limited to
documentation. We already have issues with emacs bytecode, and the next
debate that's sure to come up is language catalogs. (Do I need to have
Romanian and Portuguese messages installed for balsa?) Are we going to
hack in a special case solution each time a minor variant on this
concept crops up? Or should we try to find a cleaner solution to the
underlying problem?
I freely grant that coming up with a more general solution (one that
*doesn't* involve classifying files an a package as "documentation",
"language catalog", "binary", "other", and whatever else we may end up
needing) may require more work and more coding up front, but it the long
run, I predict it will turn out to be a Big Win.
If I seem to be arguing both sides of this debate, well, perhaps I am.
I think that it's a good idea in the abstract, but I also feel that a
technically flawed or overly limited solution is worse than no solution
at all.
--
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: