You are not logged in.
Hi,
my AUR package should check for an existing backup of config data before upgrading the package. If there is no backup, the upgrade should abort.
However, my attempt to stop the upgrade with "exit 1" did not succeed. How can I perform this?
Offline
I assume you're using the pre_upgrade section of an .install script for that ?
please post your .install file and PKGBUILD
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Can you explain your usecase? If you're trying to prevent overwriting a customised config file, I'm wondering why you're not just using the backup array in the PKGBUILD.
EDIT: Moving to Creating & Modifying Packages.
Last edited by WorMzy (2015-11-21 12:40:50)
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
That won't work - pre_upgrade is run before that particular package is updated. As that could be in the middle of a system update, aborting the update may lead to an unusable system.
You will be able to do this with hooks in the next pacman release.
Offline
My use case is the following package:
https://aur.archlinux.org/packages/upsource/
The new major version requires an import of old backup files. I would like to abort the upgrade process if no backup is available.
Offline
Windy,would it be sufficient to check for an existing backup at build-time ?
If so,you could add the backup-check to the PKGBUILD body (before any functions) and use ||return 1 to have the build fail.
(add an echo statement so the user will know why the build fails).
It's not ideal, but should work for an AUR package.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
I'm still not getting the reasoning behind this. Presumably it is possible to run the software without this backup, or else people who install v2 directly (not upgrading from v1) will be unable to run it.
It seems you're trying to automate the migration for users. I strongly recommend against that. Displaying a message in the post_install scriptlet explaining what the user needs to do to migrate their configuration should be sufficient.
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
It seems you're trying to automate the migration for users. I strongly recommend against that. Displaying a message in the post_install scriptlet explaining what the user needs to do to migrate their configuration should be sufficient.
Normally I would agree to this, but Upsource requires a backup made with the previous version. Once the update is done, there is no way other than downgrading again and performing a backup.
Offline