[Slackbuilds-users] txz?

[David Chmelik]

On 10/5/26 6:19 PM, B. Watson wrote:
> On Mon, 5 Oct 2026, David Chmelik wrote:
>
>> When it's Slackware v16, SBo could maybe upgrade to txz by default, 
>> right?
>
> You can make this the default already on your own Slackware box
> by putting "export PKGTYPE=txz" in the environment (like, in
> /root/.bashrc or such).
>
I did years ago but SBo .SlackBuild files still use tgz and I run many 
(not most) manually so end up redoing.

>> It's been Slackware standard for many years
>
> Slackware packages are generally built once (by Pat) and downloaded
> many times (by everyone else). So it makes sense for him to save a
> slight bit of bandwidth by using XZ compression.
>
> Built SBo packages are generally built on the system they're going to
> be installed on, or anyway aren't distributed over the Internet. The
> typical use case is to build the package (compressing it), then
> *immediately* install it (aka uncompressing it). The amount of local
> storage saved by using XZ might not outweigh the extra time spent on
> the better-but-slower XZ compression and decompression.
>
> My gut instinct is that using .txz by default isn't worth the extra
> time spent in compression, but that's not science...
>
> Hard numbers would be good. Maybe you (and me, and a few others) could
> actually benchmark it on real-world systems we actually use, with SBo
> packages of various sizes, and see what the results look like?
>
> I did just time "gz -9" vs. "xz -9" for a 99MB font package, and
> the results were that xz took almost 3x as long to compress it (16.7
> sec vs. 6.5)... but the resulting compressed file was 3.2MB (the .gz
> one was 55MB). That's a single data point, can't extrapolate from it
> really.
>
You have some major point.  I think I'd still use txz for fonts and some 
things to save space, but it sounds like for other things I might want 
to save time and not upgrade yet.

> Hopefully others weigh in with their own opinions. Anyone?
> I would also suggest considering .tlz packages using plzip.
>
> Slackware’s makepkg already supports the .tlz format, and
> automatically uses plzip for multithreaded compression when it is
> available.
>
> The number of threads can also be selected with --threads.
>
> The lzip format was designed with a strong focus on data integrity and
> recovery from corruption. Antonio Díaz Díaz, the author of lzip and
> plzip (and also ed), has written an interesting article about some of
> the design and reliability issues surrounding xz:
>
> https://www.nongnu.org/lzip/xz_inadequate.html
>
> .txz is certainly the safest default for compatibility, but .tlz could
> be a valuable alternative for Slackware users who prioritize
> robustness and parallel compression.
That all sounds good, and might partly solve the time issue?  I've 
definitely had txz packages been called corrupt several times, but 
haven't seen it for tgz.  How is tlz for saving space with binaries though?

> On Mon, Oct 5, 2026 at 9:52 PM David Chmelik <dchmelik at gmail.com> wrote:
>> When it's Slackware v16, SBo could maybe upgrade to txz by default, right?  It's been Slackware standard for many years--if not 10+--and there are a few newer types.  One was maybe tlz which was tried briefly but maybe only better for text and not great for binaries,  There's now a newer one I expect might be tried, that might be called zstd or something but I expect will have its own shorter extension or maybe is an upgrade/improvement to txz.