Re: [proposal] remove the requirement to compress documentation
Package: debian-policy
Version: 3.9.2
Severity: wishlist
On Mon, Feb 20, 2012 at 09:17:16PM +0100, Iustin Pop wrote:
> On Mon, Feb 20, 2012 at 08:22:52AM +0100, Wouter Verhelst wrote:
> > Hi,
> >
> > During a recent discussion on debian-devel about multiarch, it was shown
> > that gzip does not always produce the exact same output from a given
> > input file.
> >
> > While it was shown that removing the requirement to compress
> > documentation would not solve the issue (i.e., the problem was larger
> > than just the compressed files), I still think removing the requirement
> > to compress files is a good thing to do.
> >
> > Rationale:
> > - While I'm sure compressing files would have been a useful thing to do
> > in the days of 500MB-harddisks, the same is no longer true for today's
> > hundreds-of-gigabytes harddisks. A simple test[1] shows that the
> > increase in diskspace is negligible in relation to today's disk sizes.
> > - In the cases where the increase in diskspace would be significant,
> > i.e. in embedded systems, the best option is to use emdebian, which
> > already routinely removes *all* documentation from the system as part
> > of the modifications they make to Debian proper; so this change would
> > not impact embedded users.
> > - Compressing documentation files incurs an additional step on the user
> > who wants to read said documentation. Yes, there is zless and zmore.
> > However, there is no ziceweasel, zpdf-reader[2] or zgv. Even if such
> > tools do exist, we would still require that users either know these
> > tools exist and how to get them, or to decompress files before reading
> > them.
> >
> > As such, I believe the requirement to compress files is an anachronism
> > that we should get rid of.
> >
> > Thoughts?
>
> Good idea, seconded.
That makes three; while the proposal definitely needs more work, I think
that makes it time to file a bug on this so it can be properly tracked.
One thing I haven't talked about yet is man and info pages. While I feel
very strongly that we shouldn't compress files under /usr/share/doc
anymore, I don't feel as strongly about man and info pages. Yes, these
are documentation as well; but since nobody reads man or info pages
except through tools that all support transparant decompression, the
question then becomes what sets them apart from other documentation.
I guess the answer to that question is the fact that you start reading
documentation under /usr/share/doc with a filename, whereas you start
reading man or info pages with a keyword. As such, how this
documentation is stored is a technical detail; not so when you need to
use a filename.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: