From: James Cloos <cloos@jhcloos.com>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: why? pciutils with zlib use-flag went stable on x86
Date: Thu, 02 Aug 2007 08:23:40 -0400 [thread overview]
Message-ID: <m3ir7yqg4c.fsf_-_@lugabout.jhcloos.org> (raw)
In-Reply-To: <f8ikrq$78k$1@sea.gmane.org> ("Sven Köhler"'s message of "Sun, 29 Jul 2007 20:04:18 +0200")
>>>>> "Sven" == Sven Köhler <skoehler@upb.de> writes:
Sven> Oh! So USE="hal" forces pciutils not to use zlib?
There are many more ebuilds than just hal which fail with a compressed
pci.ids file. And many of them are non-obvious. It took me more than
I little bit of effort after the zlib USE flag was first added to the
pciutils ebuild to figure out why so many packages where failing...
(On an old enough install, with enough disparate packages installed, a
naïve emerge world will always fail. *Something* is guaranteed to be
unhappy.)
The lunacy is that compressing pci.ids and usb.ids helps no-one. On a
system running from a spinning disk the size difference is lost in the
noise. On embedded systems one knows in advance what devices exist on
the motherboard and can edit the ids file down to just those. Most
embedded systems don't even need the ids files on the production load.
No developer worth his salt would waste space on names where the numbers
work just as well. They'd use the names on the development platform, of
course, but those would be complied to just the ints on the final load.
So, simply put, compressing pci.ids benefits no-one, and harms many.
A cool hack perhaps, but misguided and useless.
The pciutils ebuild should be re-engineered to use separate USE flags
for linking to libz and compressing the database. Or the database
should be an ebuild of its own, using a custom flag (compressed?) to
request compression of the ids file, and not the zlib flag.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-08-02 12:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-29 16:44 [gentoo-dev] why? pciutils with zlib use-flag went stable on x86 Sven Köhler
2007-07-29 16:53 ` Mart Raudsepp
2007-07-29 17:53 ` [gentoo-dev] " Sven Köhler
2007-07-29 17:27 ` [gentoo-dev] " Wulf C. Krueger
2007-07-29 19:15 ` [gentoo-dev] " Ryan Hill
2007-07-29 21:01 ` Seemant Kulleen
2007-07-29 17:36 ` [gentoo-dev] " Carsten Lohrke
2007-07-29 17:45 ` Carsten Lohrke
2007-07-29 18:04 ` [gentoo-dev] " Sven Köhler
2007-07-29 18:24 ` Arfrever Frehtes Taifersar Arahesis
2007-07-29 18:46 ` Steev Klimaszewski
2007-08-02 12:23 ` James Cloos [this message]
2007-08-02 13:15 ` Steve Long
2007-08-03 1:39 ` Chris Gianelloni
2007-08-02 16:26 ` Sven Köhler
2007-08-02 23:19 ` Ryan Hill
2007-08-02 23:50 ` Robin H. Johnson
2007-08-03 0:07 ` Ryan Hill
2007-08-03 1:37 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ir7yqg4c.fsf_-_@lugabout.jhcloos.org \
--to=cloos@jhcloos.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox