Flexibility and inter-operability are the first two things that spring to mind. There are probably many more reasons.
No, but you can do
and it will work.

In this context, the "format" of the package will be the internal organization of the files, dirs, and how the slackware package manage handles it. The compression algorithm used is irrelevant and should be completely transparent to the user. I fail to see any reason too complain, or even to care at all about this.

rpm's used to be compressed with bzip2, now they use lzma. The end user do "rpm -whatever packagename", I doubt most of them even noticed the change.

Eloquently put!

Exactly! If it was transparent to the user I'd agree. But the possible use of 4 different file extension suffixes on package files is what worries me from a userbility standpoint. If the compression was hidden from the user and all the packages were named '*.package' I wouldn't have a problem with the idea at all.

I agree with GazL.

However I believe Slackware 13.0 (or whatever it is called) will ship with packages having only one type of file extension (otherwise you would need more than one DVD). So I assume that only one file extension will make it at the end as "official" package file extension and it will be the one shipped with the next version.

As a consequence, I envision that sites providing additional packages or Slackbuilds (slacky.eu, slackbuilds.org...) will switch to the next "official" file extension to be in line with the KISS principle (.i.e. provide extra packages using the same file extension as in the shipped DVD even though the package tools allow for other extensions). This in turn will reinforce the status of that file extension as "official".

Just my 2 cents

I think you're right there gegechris. It'll sort itself out in time, though we'll probably have a short period where packages will be showing up with the old .tgz and the new .twhatever for a while until all the 3rd party package maintainers react to the change. Anyway, its not something that can't be lived with, so not a big deal.

I'm glad to see the official pkgtools add support for bzip2/lzma compression. src2pkg has been supporting tbz and tlz package formats for over a year now, and I already had my mind set on adding support for the txz format as well. I've been using my own modified version of pkgtools which included tbz/tz support -although I usually just use tgz anyway. But, using lzma can mean good space saving and lzma is nearly as fast as gzip decompressing and much faster than bzip2.

What about RAM usage? It should depend on some of the parameters used compression but AFAIK LZMA will require quite a bit, compared to gzip or bzip. On the net I found some benchmarks:



So, if Slack uses LZMA and still wants to be installable on a 16 MB system, level-6 is the best one can hope (given the large 2.6 kernels). It should still save considerable space, but if such a transition is to be made, I think it makes more sense to forget about archaic computers altogether and require larger RAM, modern CPUs and compile the packages with >=i586 optimizations.

If you wanted to make it 'transparent' to the user, why not be ultimatly retarded and have <pkgname>-<version>-<arch>-<build>.t??.slkpkg

then EVERYBODY knows there is no confusion that it's a slackware package and for those that care, they know what compression it is without doing something like "pkgtool --type *.slkpkg" or Bob forbid "testpkg --type *.slkpkg"


The better questions you should be asking your selves are:
what kind of system can handle better compression algorithms?
Can an i486 system with less than 128 mb of ram decompress the highest compression ratio?
who is the target audience of slackware 13?
Is this feature for distributed copies of slackware or for ancillary package maintainers?


I would be more concerned about confusing matters by having the purchasable copy as a set of 6-8 CD's all with .tgz while download versions are all .xlz.


I guess slackware users shouldn't really concern them self either way unless they have that i486 system and are going to try to run KDE4 off of it.

Because that wouldn't be transparent.

I was using definition 7 which is the usual meaning of the word when used in relation to computing or software. Your example is more in line with definition 4, which is the exact opposite. (Isn't english a wonderfully stupid language.)


I don't think the user should have to be aware of, and especially not have to care about the type of compression being used in the package. Your example above of including the compression type in the filename is exactly what I was suggesting should be avoided.

All the user cares about is whether the file is a slackware package or not. A single suffix (however it's named: .slackpack, .package .slpkg or whatever) is all that is required and personally I think would be preferable to several different suffixes identifying the compression type used.

.deb, and .rpm's don't include it, and I am suggesting that if the package format is to change, then now might be a good time for slackware to consider doing something similar.

There are precedents for using tgz, tbz and tlz to denominate binary packages. I see that the new pkgtools are also supporting tar.bz2 and tar.lzma, etc. I somehow doubt that PatV will be going to a proprietary package suffix. I prefer to see binary packages with tgz. tbz, tlz or txz, with the longer forms (tar.gz tar.bz2, etc) used only for sources.
About the memory requirements for lzma, I think those requirements have changed since that web-page was created. IIRC, the kernel patch which adds lzma and bzip2 support to the kernel mentions about lzma only needing a max of 8MB RAM for decompression. The new xz format may do better than the old lzma. Using the old lzma format has another disadvantage in that the archives can't be reliably identified using 'file'. The xz format now has 'magic' which can be detected by 'file'.

If you really break it down, a slackware package is a tar file first. So really gzip is the first infidel. Now that I think of it, we could be ultimately retarded and call a .slkpkg nothing more than a tar file with a properly formatted header block which basically just had the information from the /install folder in the package. Then we would have .slkpkg.gz (or others). And in true slackware fassion we would be back at .t?? only now it would be .s??

wait... isn't obfuscating things the problem with the other operating systems?


Anyway, my previously mentioned suggestion is 'transparent' enough. People that shouldn't be using slackware would see a .slkpkg and instantly be in ignorant bliss while all other users would know what it is with the other tag. Maintainers already have build tags. So if the .t??. didn't get added as a standard addition then it would get swallowed by the <build> tag which would ultimately become something like *-1_tgz_SBo.slkpkg. You would not be able to stop and it probably would get added into the scripts at slackbuilds. UNLESS a new commands were added to tell the type and or just extract the package. Like 'testpkg' and 'extractpkg'

<pkgname>-<version>-<arch>-?_t??_SBo.slkpkg

The following is a snippet from another thread posted in this forum today. I post it here as it shows exactly why I advocate that slackware packages should have their own unique suffix.

Quote:

Originally Posted by Dinithion Where did you get the package? .tgz is usually installed thisway: installpkg <package> as root, i.e: installpkg ip_wccp-1.7.tgz

Quote:

Originally Posted by knudfl @ Dinithion : ip_wccp-1.7.tgz is the source code with a wrong suffix.

Technically, it's not the 'wrong suffix' .tgz is a 8.3 dos filename compatible contraction of .tar.gz that has been used for years and is being used quite correctly here. You're most likely to see it used on source tarballs who's primary target is a windows system.

A slackware package file is just a .tar.gz archive file who's contents just happen to be a slackware package, so using a .tgz suffix is also quite proper but it can lead to confusion, as shown above.


Anyway, I'm not going to labour the point any further. Pat and the team will make up their own minds on this one, and I suspect that gnashley is right and that they'll be unlikely to want to change to a proprietary suffix after all these years. But if they are intending to change the default compression scheme/suffix anyway, then this is the right time to bring these sorts of suggestions to their attention.

That confusion caused by .tgz = .tar.gz and .tgz = Slackware package has cropped up a few times on these forums. If only people read and took notice of the full name of the thing in question, that confusion would be avoided.

Hmm... according to the changelog it seems like a lot of packages are getting rebuilt for support for the new package formats.

Also I notice that alot of tags are being dropped from the end of the packages