It seems like Patrick is considering other options.
Why do you think other compression formats would be useful?

Unfortunately the other formats tend to be slower at decompressing than gz, but they also have better compression ratios. It's a trade-off. Maybe to speed it up a C program should be made, kinda like spkg. That would speed up the install phase enough that the decompression phase may not matter.

Overdue, IMO.

Slackware's getting bigger. I guess there has to be better compression alternatives if it's going to need to continue to be able to fit on a DVD.

I can understand wanting to move to a newer/stronger compressions algorithm such as bz2 to be able to fit more onto the dvd media, but supporting 4 of them seems a little over the top and decidedly unslackwarelike. Oh well, I guess he has his reasons. Perhaps he's just experimenting with them all and will choose one of them prior to the 13.0 release.

Really? Slackware supports more than 4 compression formats. Has done for quite some time. Extending the package manager in this way only makes sense. To me, anyway.

lol, you know damn well what I meant!

I just don't like the idea of having more than one format for a package (even if it is only the compression used that changes). It's bad enough with .deb, .rpm and all the others without slackware having several to choose from all of its own.

Anyway, as I said, he's probably just trying them all out to see which is best.

... by "unslackwarelike" ??? No. Who decides what is "Slackwarelike"?
I don't see a problem with it. Personally, I think it opens up some positive options. Back when I first started using Slackware (v7.0), I changed the scripts to support tbz packages myself.
Maybe. There are better ways of benchmarking compression formats though.

What's to say that PV is going to use any of the formats himself? Support for something doesn't automatically mean anything. Perhaps people are jumping to conclusions here. Slackware supports rpm packages, but does PV ship any?

Can you do This is modifying the slackware package tools, not shipping an rpm-4.4.2.3-i486-2.tgz package.

Perhaps the answer lies in this entry in the Changelog.

Well, within the context of trying to communicate my opinion, It's my definition that matters as that's what will convey the message I was trying to put across. I thought the regulars here would understand what I meant by that, but I guess it's a bit too generic a term and may mean different things to different people.

Anyway, to make myself clearer; to me, 'Slackwarelike' means following the "keep it simple" philosophies.

Having One single package format is significantly simpler to me than having four supported formats to choose from. I really don't mind which of the four is used, but I do believe that there should only be one 'official' format used for the sake of simplicity. There's nothing to suggest that this isn't still the case so it's really not worth making a big deal out of this. I just posted my comment as I thought this change was a little strange that's all.


You're quite right about adding support for, and adopting the use of being completely different things, but if you're not going to do the latter, why do the former?

As ever, this is just my personal opinion which has differed to that of others on here before and I'm sure will do again in future.

So does this mean that Slackware will now support FreeBSD packages (.tbz)? I don't know of any Linux distros that use .tbz, only FreeBSD. I don't even know what .tlz, and .txz are from. Never heard of those.

Look at makepkg, then you will see that there is basically no difference. The tar file is generated the same way in all formats, the only difference is what compression is applied to the tar file.

I see nothing else changed in the way the package is created with the new pkgtools.

From a newbie: KISS, one format....I'm having trouble remembering the one format....lol

I'll echo titopoquito a bit: It's not really a new package format, just alternate compression schemes. It's still a tarball of new files to be extracted to / and has a special install/ dir with doinst.sh and slack-desc. When I saw this thread I first thought that The Man might have been switched to PET packages or support some dependency checking (and thus invalidate current existing packages). I sometimes wish that pkgtools supported a dorem.sh for extended cleanup when uninstalling the package.

Anyway, this compression support is rather exciting to me cause now src2pkg can detect if installpkg supports these alternate compression schemes and make packages with the "best" compression possible.

Smaller packages are always better, no matter what. It's rather silly to worry about decompression speed since installing a package is inherently slow. Memory usage does matter somewhat though. It's not good for a package installation to take over the system completely.

I remember when Archlinux was going to do the same thing.

Here's one of the tests performed.

lzma is interesting, there's a ~9% file size reduction in the case above. RPM (Suse) already uses lzma

Of course some things compress better than others, but even a 5% size reduction on 4gigs of data adds up

And the reason (I assume ) is because of this update
l/libarchive-2.6.2-i486-1.tgz: Added libarchive-2.6.2.