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

Re: Bug#660705: [proposal] remove the requirement to compress documentation

On Tue, Feb 21, 2012 at 12:51:42AM +0100, Wouter Verhelst wrote:
> > > 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?

The change could be as simple as this:

--- a/policy.sgml
+++ b/policy.sgml
@@ -10634,8 +10634,7 @@ END-INFO-DIR-ENTRY
          be installed at the discretion of the package maintainer.
          Plain text documentation should be installed in the directory
          <file>/usr/share/doc/<var>package</var></file>, where
-         <var>package</var> is the name of the package, and
-          compressed with <tt>gzip -9</tt> unless it is small.
+         <var>package</var> is the name of the package.

It is interesting that dh_compress(1) says "files that Debian policy
mandates should be compressed, namely all files in usr/share/info,
usr/share/man, files in usr/share/doc that are larger than 4k in size"
while the policy says only about "plain text documentation". Maybe I'm
missing something.

> 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.
I'm not sure that this is even a question, I totally agree with the
reasons to leave this as is and don't see reasons to change this.


Attachment: signature.asc
Description: Digital signature

Reply to: