Re: bzip2 X
Bdale Garbee <firstname.lastname@example.org> writes:
> In article <19980419230406.21011@hazel> you wrote:
> : Hmm... it's actually probably a good idea to bzip2 the X sources.
> : They're monstrous.
> Probably a good idea. However...
> The right way to handle this is for someone to broach the subject of using
> compressors other than gzip for source packages over on debian-policy. At
> the same time, take up the issue with the dpkg maintainers since dpkg-source
> will need to be updated.
> As maintainer of gzip for Debian, I do not agree that having gzip fork a
> bzip2 when it sees a bzip2 magic number is a good idea. If we want to support
> multiple compression engines, I believe this should be handled in dpkg-source.
Changing dpkg* to support bzip2 (or other packers) would be a good
thing, but haveing gzip know about bzip2 would be far nicer, much
easier (and less risk of bugs) and much more general.
Fonts for X could be stored as bz2 instead of gz, man-pages could be
bz2. Many other static data could be bz2. Wherever static data is
stored as gz, bz2 could be used. Much more programms than dpkg would
benefit from that and for people with fast cpus with little
harddrives, it would be real handy.
I want to have bzip2 for everydays use and not just for installing or
unpacking debian sources and I want it as transparent as possible. I
wrote a little wraper that can distinguish between the packers and
then chooses the appropriate one. Because its a wraper its slow and
generaly I dislike wrapers, but it also works great and is done
fast. Its not agood solution, so thats why I asked here about
integrating bzip2 support into gzip. Integrating it into dpkg* just
wouldn't cut it.
May the Source be with you.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org