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

Re: [proposal] remove the requirement to compress documentation



On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert 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.
> 
> Hello Wouter,
> 
> > 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), 
> 
> To be honest, I am not sure why you are taking the trouble to bring it up,
> under those circumstances.

Because I've long thought that compressing files is not a good idea;
this just triggered me enough to come up with a proposal.

> > 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.
> 
> 500MB is not negligible. This is 5% of /usr on your system, but this can be higher
> on other system with a different package set.

There's more than just my /usr. This system runs off a 160GB SSD, so
500MB is more like 0.5% of the available storage space here.

160GB is in the low end of the available storage of modern systems, and
probably (gut feeling) about average of systems bought in the past few
years (my three-year-old HP laptop came with a 160GB rotating disk).

People who use smaller disks are also likely to have less software
installed[1], so the impact would probably remain around the same
number.

[1] At least I know that when my storage space runs out, my first reflex
    is to run aptitude and remove all those old and silly things that I
    installed once but don't really need anymore, rather than starting
    to see which parts of my homedirectory can be moved off to an
    external USB hard disk or some such.

> > - 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.
> 
> iceweasel handle compressed file fine

Only if you go through some extra effort (and install some extra
software -- why compress if you need to install extra software to read
it?).

> and so does zxpdf. 

That is yet another tool that a user needs to know about.

Another disadvantage of compressing tools (I forgot to mention this
originally): referring to documentation gets clumsier; e.g., a hyperlink
in an HTML file will probably become a dead link.

> > As such, I believe the requirement to compress files is an anachronism
> > that we should get rid of.
> 
> I do not like removing a useful requirement in exchange for nothing. 

I would agree with that statement, except that I don't think compressing
files is very useful anymore.

> Debian is used on small systems where users still like to have documentation, and
> support zlib compression is almost universal.

I would not have any objection against a tool which would compress files
upon installation for those users who want it. But I don't think having
to compress files inside the .deb package buys us very much anymore.

As to your remark about small systems: these are either going to be
embedded systems (where the better option is to use emdebian, and then
this is a non-issue), or very old and slow systems (in which case you
really really don't want to be adding more processor requirements to
users in order to allow them to read anything -- and I know what I'm
talking about here, I do m68k stuff).

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


Reply to: