Re: Suggestion to and how to alow different compression for .debs
On Wed, Oct 27, 1999 at 06:23:44PM +0200, Goswin Brederlow wrote:
>
> Without that you have to unpack the .deb file, look around for a
> data.tar.xxx and make a switch/case over xxx. Each compressor would
> need its own entry there and as soon as the third compressor comes up
> for debian packages a lot of work is saved with my idea.
That's completely untrue. Try "ar t foo.deb" and you will get the contents
of the .deb. Like I said, I already have this implemented (I also have a
bug filed against "file" for an update to the magic parsing for .debs so
it shows the compression type, easy huh :). The only thing needed for
dpkg-deb to parse any other compression types is a simple addition of a
single line for each one to the struct (this feature is based off of a bug
report in the BTS). It's very quick and it works on the fly, not having to
worry about an "uncompress.sh" being pulled from the control.tar.gz and
forking to pipe through it.
> I´m not suggesting that deb packages should be allowed to use any
> compression they like, but that dpkg and similar should be changed to
> handle arbitrary compression instead of just the few allowed once
> (namely gzip and hopefully soon bzip2).
>
> I call for generality here. Just think about the guy who said that 6
> characters for a date will be enough. :) Two, three, four or even
> houndert different compression formats could prove to be one less than
> needed.
That's a bad analogy, what about the OS that allowed too many features
only to let itself bloat and become unusable (Windows?).
> My idea would carry the needed knowledge to unpack a package to the
> package itself and therby to the place that should realy know how to
> deal with the uncompresson.
No, compression types should be discernable by extension, and in the worst
case "magic" on the data header. Why have _all_ of the packages include
this file, when at most there will only need to be 3 or 4 different ones?
Then we leave ourselves open to problems, not to mention the "I'm better
than everyone else, so I'll rewrite my script and make it better" type of
poeple, or the ones who decide to user crazy and rediculous compression
types.
Ben
Reply to: