Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64028 - [base] Remove compressors

Attached to Project: Arch Linux
Opened by Sébastien Luttringer (seblu) - Sunday, 06 October 2019, 10:14 GMT
Last edited by Sébastien Luttringer (seblu) - Sunday, 06 October 2019, 10:25 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

I suggest to remove compressors, they have to be pulled by deps by packages which require them.
This task depends upon

Comment by Eli Schwartz (eschwartz) - Sunday, 06 October 2019, 13:46 GMT
They are tiny packages -- a hundred kilobytes here, a hundred kilobytes there -- which represent the "standard" compression algorithms. I don't see much point in removing them, and especially especially not removing gzip.

Anyway, it's not like a valid archlinux system can do without them as they are required by libarchive and therefore pacman.
Comment by Bruno Pagani (ArchangeGabriel) - Sunday, 06 October 2019, 13:47 GMT
That’s not the point: if someday pacman stop using libarchive but directly e.g. zstd, then they won’t be required anymore.

To be on that `base` list, they should be required by themselves.
Comment by Eli Schwartz (eschwartz) - Sunday, 06 October 2019, 14:32 GMT
Well, yes, that is sort of the point. gzip is pretty much considered the standard compressor, and it's exceedingly useful to not be rendered unable to use basic compressed files.

xz is quite standard in a linux-specific way, but I'd argue even bzip2 is sufficiently useful that you don't want to be rendered unable to even read some fairly common file distribution formats out of a desire to save 150 kilobytes. Hence "required for itself".

The fact that pacman requires them simply means that any desire to remove them from base must be based on ideological purity rather than an actual desire to remove it from minimal systems in practice.
Comment by Sébastien Luttringer (seblu) - Sunday, 06 October 2019, 15:02 GMT
If by linux standard you mean LSB[1], gzip is inside but not bzip2 and xz.
Would be easier/simpler to rely on that standard, but the cost would be to pull command like lp (from cups), mailx (from s-nail) which are not really necessary nowadays and with a lot of dependencies.

[1] http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common/rcommands.html#TBL-CORECMD
Comment by Eli Schwartz (eschwartz) - Sunday, 06 October 2019, 15:25 GMT
I'm not referring to the LSB :p I'm referring to the somewhat more useful standard rule of thumb.

xz and gzip is what people in practice will overwhelmingly use when they want to compress files and move them around, depending on whether they care more about portability and CPU time, or bandwidth.

bzip is not overwhelmingly used, though -- it is merely technology that has been around since 1996 and been stable since 2000, available on most/all Linux systems, and therefore used by lots of people if not most people. (And also before xz came on the scene, it was *the* popular go-to for "better compression than gzip at the cost of a bit more processing time".) So there will still tend to be an awful lot of places where bzip2 is used, and it's valuable to be interoperable with that. But I could potentially hear the argument that it's not quite as important these days. (I still think 150KB is a very cheap price to pay for ensuring data portability.)

Loading...