From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-143567-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 500331381F3
for <garchives@archives.gentoo.org>; Wed, 19 Dec 2012 22:17:02 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 4E9E521C068;
Wed, 19 Dec 2012 22:16:47 +0000 (UTC)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id B654C21C04E
for <gentoo-user@lists.gentoo.org>; Wed, 19 Dec 2012 22:15:17 +0000 (UTC)
Received: by mail-wi0-f177.google.com with SMTP id hm2so1580226wib.4
for <gentoo-user@lists.gentoo.org>; Wed, 19 Dec 2012 14:15:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:in-reply-to
:references:organization:x-mailer:mime-version:content-type
:content-transfer-encoding;
bh=zcoQ0cokRe62A8H0oZCrzhcPnN2zFh6tz/LNMpEeqR0=;
b=pYUCgIJfC6DlVLtUIrzgPGYB9tYbElWmu22rYnKZqZr2yrWXzSeUF1XtNMGFr/yc52
bRvILEjeq6SCTU7ot/BUlTJQMZeYmKqwdWnI4TjtxEqXKFoWNWLeLTOUCXXbRlTBz5hf
FhKtdu1zb3/vpYIvkjYOzE8vCkjqWJyDNvcKuEur5GyzkM9p9YxBsQ0fi1otAxUR1HlR
M6lCOurZ9ydSv/t9Ttw2fmNiWSTfbKR5US6essJJpIU6vPWtbrMvtJxFxz02KWKLKNig
xFxjMTMEJNeqL46kOTZyd/BEMSIg0HA1ZY3hiAfOt9d6Rx3kCK4MPPT+xJTkCueBnrzG
JPwQ==
X-Received: by 10.180.83.169 with SMTP id r9mr13730415wiy.10.1355955316409;
Wed, 19 Dec 2012 14:15:16 -0800 (PST)
Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117])
by mx.google.com with ESMTPS id s16sm17485844wii.0.2012.12.19.14.15.13
(version=SSLv3 cipher=OTHER);
Wed, 19 Dec 2012 14:15:15 -0800 (PST)
Date: Thu, 20 Dec 2012 00:11:38 +0200
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Cc: fturco@fastmail.fm
Subject: Re: [gentoo-user] Some files in /usr/share/doc are not compressed
Message-ID: <20121220001138.754a8d88@khamul.example.com>
In-Reply-To: <1355935290.8809.140661168019761.15C370C7@webmail.messagingengine.com>
References: <1355935290.8809.140661168019761.15C370C7@webmail.messagingengine.com>
Organization: Internet Solutions
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.14; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 6d266a93-fc28-4771-bae2-d7ccb548902b
X-Archives-Hash: 2f01802849e3ef50c84e7f2fcf052497
On Wed, 19 Dec 2012 17:41:30 +0100
Francesco Turco <fturco@fastmail.fm> wrote:
> Hello.
>
> On my system Portage uses the following two variables for compressing
> files in /usr/share/doc:
>
> > $ portageq envvar PORTAGE_COMPRESS
> > xz
>
> > $ portageq envvar PORTAGE_COMPRESS_EXCLUDE_SUFFIXES
> > css gif htm[l]? jp[e]?g js pdf png
>
> It seems anyway that some files are not compressed:
>
> > $ find /usr/share/doc -type f -regextype posix-extended ! -regex
> > ".*\.(css|gif|htm[l]?|jp[e]?g|js|pdf|png|xz)" | wc -l 79
>
> I won't list all of them here, just some examples:
>
> > /usr/share/doc/gnome-shell-3.4.2/AUTHORS
> > /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml
> > /usr/share/doc/groff-1.21-r1/pic.ps
> > /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz
>
> My goal is to have everything under /usr/share/doc compressed with xz,
> or at least to understand why something is being excluded from
> compression. Perhaps it is due to some additional rules I'm not aware
> of, or because of some bugs.
>
> I checked the ebuilds of the packages the previous files belong to,
> but I found nothing interesting.
>
> It would be great if anyone who is interested could check his/her own
> system too.
That stuff is controlled by the ebuild, IIRC ebuilds should call
function dodoc so they do with docs what you want them to do. The
function name may well have changed and been superceded since last I
looked.
The reason you find nothing interesting in the ebuild is because
something that should be there isn't. ebuilds not following rules wrt
doc files is a bug and should be filed at bgo as such.
--
Alan McKinnon
alan.mckinnon@gmail.com