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

Bug#660705: marked as done ([proposal] remove the requirement to compress documentation)

Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <87o9rlx51o.fsf@iris.silentflame.com>
and subject line Closing inactive Policy bugs
has caused the Debian Bug report #660705,
regarding [proposal] remove the requirement to compress documentation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
660705: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660705
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
control: user debian-policy@packages.debian.org
control: usertag -1 +obsolete
control: tag -1 +wontfix

Russ Allbery and I did a round of in-person bug triage at DebConf17 and
we are closing this bug as inactive.

The reasons for closing fall into the following categories, from most
frequent to least frequent:

- issue is appropriate for Policy, there is a consensus on how to fix
  the problem, but preparing the patch is very time-consuming and no-one
  has volunteered to do it, and we do not judge the issue to be
  important enough to keep an open bug around;

- issue is appropriate for Policy but there does not yet exist a
  consensus on what should change, and no recent discussion.  A fresh
  discussion might allow us to reach consensus, and the messages in the
  old bug are unlikely to help very much; or

- issue is not appropriate for Policy.

If you feel this bug is still relevant and want to restart the
discussion, you can re-open the bug.  However, please consider instead
opening a new bug with a message that summarises and condenses the
previous discussion, updates the report for the current state of Debian,
and makes clear exactly what you think should change.

A lot of these old bugs have long side tangents and numerous messages,
and that old discussion is not necessarily helpful for figuring out what
Debian Policy should say today.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: