You are not logged in.
Since pacman commit https://git.archlinux.org/pacman.git/co … 5c80f13b62, support for upx is removed. For an aur/pacman-git user, if a PKGBUILD contains !upx in options, an error will occur when running makepkg:
==> ERROR: options array contains unknown option '!upx'
As a PKGBUILD maintainer for some packages, I have some choices:
* Keep !upx in options and tell pacman-git users to modify PKGBUILD manually
* Drop !upx and tell core/pacman users to remove upx from their /etc/makepkg.conf
* Ask pacman developers tolerate the existence of upx and optipng in PKGBUILDs for now
Which is a better approach?
Offline
Are there any examples of PKGBUILDs which explicitly require that upx be disabled?
The upx option is disabled by default, so I think the likelyhood of a user both having enabled it, and building a package which explicitly requires that upx is disabled, is quite slim (hell, it's taken two years for anyone to ask this question, as far as I'm aware!).
I would just remove the option from the PKGBUILD. Maybe pin a comment if upx users ask why the package no longer works for them.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Are there any examples of PKGBUILDs which explicitly require that upx be disabled?
Here are two examples:
* insync https://aur.archlinux.org/packages/insync/
* dropbox, before the latest change https://aur.archlinux.org/cgit/aur.git/ … 67b3871cd8
Both have comments about upx breaking the package.
And both are proprietary! Maybe not a coincidence
I would just remove the option from the PKGBUILD. Maybe pin a comment if upx users ask why the package no longer works for them.
Thanks for the suggestion!
Last edited by yan12125 (2018-03-25 09:19:24)
Offline
I've been locally patching out the !upx option for Dropbox for like years now. I think it is the responsibility of AUR users to be aware of when their own unusual modifications to makepkg.conf break things, and you're going to have to remove it soon anyway...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline