Hi guys,
I maintain the multiload-ng AUR packages, in particular xfce4-plugin-multiload-ng-gtk2 and xfce4-plugin-multiload-ng-gtk3. After the recent Xfce 4.16 update the gtk2 version stopped building, so I would like to delete xfce4-plugin-multiload-ng-gtk2 and somehow migrate the users to xfce4-plugin-multiload-ng-gtk3 (which should be renamed to just xfce4-plugin-multiload-ng if possible). What are my options making the transition as smooth as possible?
Thanks for any input and merry Christmas! Michael
Hi Michael, you can use 'replaces': https://wiki.archlinux.org/index.php/PKGBUILD#replaces
If the package should stay on the aur this still does not help much, so you'd need to write a comment to the aur package page and tell users to move to the new package. I'd keep it a month and then open a deletion request.
People with an aur helper will possibly miss the change if they dont subscribe on updates, but they will possibly notice the missing package, I am not sure. No matter what, you have no other option than that (correct me if i am wrong).
Cheers Nico
On 12/26/20 11:17 AM, Michael Kogan via aur-general wrote:
Hi guys,
I maintain the multiload-ng AUR packages, in particular xfce4-plugin-multiload-ng-gtk2 and xfce4-plugin-multiload-ng-gtk3. After the recent Xfce 4.16 update the gtk2 version stopped building, so I would like to delete xfce4-plugin-multiload-ng-gtk2 and somehow migrate the users to xfce4-plugin-multiload-ng-gtk3 (which should be renamed to just xfce4-plugin-multiload-ng if possible). What are my options making the transition as smooth as possible?
Thanks for any input and merry Christmas! Michael
Hi Michael,
I had the same problem the other day, with package passmenu-notify-git replacing pass-patched-passmenu-notify-git. There is the `replaces` directive in PKGBUILD, but I don't think that really works to automate replacement for AUR packages. I don't know if there's a standard procedure, but here's what I ended up doing.
At the bare minimum, add and pin to the replaced package a comment documenting the new package to use. I also flagged my package as out of date.
Next, I changed the package description to "DEFUNCT: Use <new-package> instead". Then I intentionally broke the package by removing all the sources and having `package()` just print an error message redirecting to the new package, then unconditionally fail. I also added `epoch=1` to the PKGBUILD to help this version of the package override other releases. If this seems too aggressive for your package, you could instead just add a warning message in `package()` and in the post-install/post-upgrade script. In my case the old package was already broken.
Hope that helps with some ideas on how to approach the issue! I'd be interested to hear others' thoughts too.
/Emil
On Sat, 26 Dec 2020, 11:18 Michael Kogan via aur-general, < aur-general@archlinux.org> wrote:
Hi guys,
I maintain the multiload-ng AUR packages, in particular xfce4-plugin-multiload-ng-gtk2 and xfce4-plugin-multiload-ng-gtk3. After the recent Xfce 4.16 update the gtk2 version stopped building, so I would like to delete xfce4-plugin-multiload-ng-gtk2 and somehow migrate the users to xfce4-plugin-multiload-ng-gtk3 (which should be renamed to just xfce4-plugin-multiload-ng if possible). What are my options making the transition as smooth as possible?
Thanks for any input and merry Christmas! Michael
Hi guys,
thanks for your input! I tried to create a new xfce4-plugin-multiload-ng package and ran into the issue that the AUR's git repository ssh:// aur@aur.archlinux.org/xfce4-multiload-ng-plugin.git was not empty but had some outdated PKGBUILD in it. But it had no .SRCINFO file and (probably because of the missing .SRCINFO) the package also wasn't listed on the AUR page. Can I just replace the outdated PKGBUILD with the new one, add a .SRCINFO and things will work out, or do I need a TU to have a look into it?
Thanks again, Michael
On 12/26/20 1:12 PM, Michael Kogan via aur-general wrote:
Hi guys,
thanks for your input! I tried to create a new xfce4-plugin-multiload-ng package and ran into the issue that the AUR's git repository ssh:// aur@aur.archlinux.org/xfce4-multiload-ng-plugin.git was not empty but had some outdated PKGBUILD in it. But it had no .SRCINFO file and (probably because of the missing .SRCINFO) the package also wasn't listed on the AUR page. Can I just replace the outdated PKGBUILD with the new one, add a .SRCINFO and things will work out, or do I need a TU to have a look into it?
Thanks again, Michael
Clone this git, override it, make a commit and push the changes.
Done, thanks! Eventually I did all of the above (a "replaces" field in the new package which seems to have no impact though, an echo output with the deprecation message, a deprecation message in the package description, a comment on the AUR page and an out of date notification with again a deprecation message). Let's see how it goes! :)
On 26/12/2020 15:39, Michael Kogan via aur-general wrote:
Done, thanks! Eventually I did all of the above (a "replaces" field in the new package which seems to have no impact though, an echo output with the deprecation message, a deprecation message in the package description, a comment on the AUR page and an out of date notification with again a deprecation message). Let's see how it goes! :)
As mentioned, replace does nothing at all for AUR packages (unless you put them in a local repo).
You can add conflicts/replaces though, such that users don't have to manually remove the old package before installing the new one.
Alad
On 27/12/2020 02:30, alad via aur-general wrote:
On 26/12/2020 15:39, Michael Kogan via aur-general wrote:
Done, thanks! Eventually I did all of the above (a "replaces" field in the new package which seems to have no impact though, an echo output with the deprecation message, a deprecation message in the package description, a comment on the AUR page and an out of date notification with again a deprecation message). Let's see how it goes! :)
As mentioned, replace does nothing at all for AUR packages (unless you put them in a local repo).
You can add conflicts/replaces though, such that users don't have to manually remove the old package before installing the new one.
Alad
...and I meant conflicts/provides in the last part.
Alad
Should those go into the new package or into the deprecated ones or into all of them? Currently I have conflicts/replaces in all three PKGBUILDs. So I just exchange replaces with provides in all of them, or I better remove those fields from some of the PKGBUILDs? Thanks!
Am So., 27. Dez. 2020 um 02:35 Uhr schrieb alad via aur-general < aur-general@archlinux.org>:
On 27/12/2020 02:30, alad via aur-general wrote:
As mentioned, replace does nothing at all for AUR packages (unless you put them in a local repo).
You can add conflicts/replaces though, such that users don't have to manually remove the old package before installing the new one.
Alad
...and I meant conflicts/provides in the last part.
Alad
On 30/12/2020 21:24, Michael Kogan via aur-general wrote:
Should those go into the new package or into the deprecated ones or into all of them? Currently I have conflicts/replaces in all three PKGBUILDs. So I just exchange replaces with provides in all of them, or I better remove those fields from some of the PKGBUILDs? Thanks!
Since the deprecated ones would likely be unlisted from the AUR anyway, I'd say it only matters for the new package.
Alad
Am So., 27. Dez. 2020 um 02:35 Uhr schrieb alad via aur-general < aur-general@archlinux.org>:
On 27/12/2020 02:30, alad via aur-general wrote:
As mentioned, replace does nothing at all for AUR packages (unless you put them in a local repo).
You can add conflicts/replaces though, such that users don't have to manually remove the old package before installing the new one.
Alad
...and I meant conflicts/provides in the last part.
Alad
aur-general@lists.archlinux.org