Proposal: Do not remove a package from the AUR until it is available in a stable repository
Hi all! Recently with the GNOME 43 update I have seen that certain packages are being removed from the AUR to go into the official testing repositories. The problem, in my opinion, is that packages are being removed from the AUR before they go into an official stable repository, which makes the packages "disappear" for a while. Not everyone has the testing repository enabled. In fact using AUR packages is not a condition for having testing, so what a user sees is that suddenly the package he/she was using disappears and he/she can't install it neither with his AUR helper nor with pacman. IMHO, I think it would be better to leave the packages in the AUR until they reach the stable repositories to avoid possible confusion. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 28/10/2022 08:00, Óscar García Amor wrote:
IMHO, I think it would be better to leave the packages in the AUR until they reach the stable repositories to avoid possible confusion.
How would you deal with the potential for diverging changes, i.e. the AUR maintainer continues to make changes while the repo maintainer is doing their development work for the repo packages?
I don't see the problem. From the moment that the AUR package goes to the testing repository a request for deletion is made, that request is received by the maintainer of the package in AUR, if from there I do not think you want to continue maintaining it knowing that in a short time will disappear and will be replaced by an official one. In any case, the official packages do not have to be packaged in the same way as AUR packages, so they will not be the same once they are moved from AUR to the official repository. Greetings. El vie, 28 oct 2022 a las 13:35, Jonathon Fernyhough (<jonathon@m2x.dev>) escribió:
On 28/10/2022 08:00, Óscar García Amor wrote:
IMHO, I think it would be better to leave the packages in the AUR until they reach the stable repositories to avoid possible confusion.
How would you deal with the potential for diverging changes, i.e. the AUR maintainer continues to make changes while the repo maintainer is doing their development work for the repo packages?
-- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
How is it right now. Are Arch packages build up on AUR packages. For example I release a AUR PKGBUILD with epoch=39, would Arch remove that, reset it to nothing or would Arch keep it? Thats important because if Arch resets it anyways, the PKGBUILD can stay on the AUR and we shouldnt care what happens on there before release. If Arch however keeps it it should be removed as it is right now, on move to testing. Am Fr, 28. Okt 2022 um 12:35:02 +01:00:00 schrieb Jonathon Fernyhough <jonathon@m2x.dev>:
On 28/10/2022 08:00, Óscar García Amor wrote:
IMHO, I think it would be better to leave the packages in the AUR until they reach the stable repositories to avoid possible confusion.
How would you deal with the potential for diverging changes, i.e. the AUR maintainer continues to make changes while the repo maintainer is doing their development work for the repo packages?
On Fri, 28 Oct 2022, Fabian Bornschein wrote:
How is it right now. Are Arch packages build up on AUR packages. For example I release a AUR PKGBUILD with epoch=39, would Arch remove that, reset it to nothing or would Arch keep it?
Thats important because if Arch resets it anyways, the PKGBUILD can stay on the AUR and we shouldnt care what happens on there before release. If Arch however keeps it it should be removed as it is right now, on move to testing.
Hi, I don't know, how aur-helper handle this, but pacman itself does not compare versions of packages in different repositories. It just looks, what repository comes first in /etc/pacman.conf. So if an aur-helper adds an additional [aur] repository in pacman.conf at the end, official packages would always take priority over aur packages. Regarding your first question: I have no idea, but I would assume, that they remove exceedingly high epoch values - but it might also be up to the packages and different from package to package. regards, Erich
participants (4)
-
Erich Eckner
-
Fabian Bornschein
-
Jonathon Fernyhough
-
Óscar García Amor