Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. 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#60894 - [pacman] change default PKGEXT of makepkg.conf to .pkg.tar

Attached to Project: Arch Linux
Opened by solsTiCe (zebul666) - Friday, 23 November 2018, 16:20 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 23 November 2018, 18:42 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Cuurently, pacman ships with /etc/makepkg.conf with

PKGEXT='.pkg.tar.xz'

The feature request is to drop the compression extension to only keep

PKGEXT='.pkg.tar'

I have never shared a binary package with anyone. I don't know the usage of every other user, so it's my opinion and I doubt that feature request might be accepted.

I build package only to install them locally. If I need to share a package with someone, I bundle the PKGBUILD and its files in an archive.

So the first thing I do, is to remove the compression extension in PKGEXT in /etc/makepkg.conf
This is useless if you install the package locally. And even if you store it for backup, given the price of the GB now you don't care. You can eventually compress it manually if need be.

So for the main workflow, building a package and installing locally, the compression stage is completly useless and just a waste of time and cpu cycle.
on ARM, this is noticeable (I know ARM is not supported here).

What do you think ?
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 23 November 2018, 18:42 GMT
Reason for closing:  Won't implement
Additional comments about closing:  OP request: well not a good idea after all. I submit this to ARM devs.
Comment by Eli Schwartz (eschwartz) - Friday, 23 November 2018, 16:39 GMT
That's exactly why this is configurable, and for packages where the compression time is non-negligible, the space savings is non-negligible as well. I have a couple GB of self-built packages and I *do* share these, as do many other people. (Among other things, building a package once and installing it on multiple home systems.)

On x86_64 systems, I don't believe the cost of compression is enough to justify something that causes no harm other than "waste of time and cpu cycle", in return for storing packages in a manner that is only useful for people who do not save their packages after installing them (something which I believe to be unwise as you cannot uninstall or reinstall).
If compression is disproportionately burdensome on ARM chipsets, this is a good time for ARM to deviate from us (something which they already do to e.g. add a sync(2) after all pacman transactions).

Aside: the (very commonly seen) idea that "given the price of the GB now you don't care" justifies frivolous waste, sort of depresses me about the mindset of people today. Waste is still waste. I'd rather save my disk space for things I find important, rather than buying a new disk for *any* price just because I'm too apathetic to compress files in storage that natively support compression.
Comment by Øyvind Heggstad (Mr.Elendig) - Friday, 23 November 2018, 16:40 GMT
Your argument for wasting cycles on ARM doesn't matter since archlinux doesn't support arm, and the arm distroes which uses pacman (like archlinux-arm) are free to ship a default makepkg.conf with .pkg.tar), I suggest you make the feature request to whichever distro you are actually using for ARM.

As for archlinux, I think either fine. There are advantages to both and there will always be users who would prefer the opposite of the default.
Comment by solsTiCe (zebul666) - Friday, 23 November 2018, 17:11 GMT
@eschwartz. I am not fond of wasting disk space either. That was kind of to push another argument. /o\

Loading...