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

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: