[aur-general] Package ownership change request for yaourt-git
Hi all, I (andrewSC) would like to request ownership of yaourt-git (https://aur.archlinux.org/packages/yaourt-git/) as it's been flagged out-of-date for some time now. Regards, Andrew
Am 03.08.2014 um 04:56 schrieb Andrew Crerar:
Hi all,
I (andrewSC) would like to request ownership of yaourt-git (https://aur.archlinux.org/packages/yaourt-git/) as it's been flagged out-of-date for some time now.
Regards,
Andrew
What is wrong with the package? The AUR maintainer is the upstream maintainer. How can VCS packages be out of date at all? So the flag is wrong. Regards Stefan
On 02/08, Andrew Crerar wrote:
Hi all,
I (andrewSC) would like to request ownership of yaourt-git (https://aur.archlinux.org/packages/yaourt-git/) as it's been flagged out-of-date for some time now.
Disregarding the fact that there seems to be nothing actually out of date with it, orphanship requests should be done from the AUR web interface now, under the 'File request' link on the package's page. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
Stefan and Johannes,
Thank you for replying to the request, I've noted that requests should
now be done through the web interface and will be updating the wiki
shortly to reflect that. I was under the impression that the PKGBUILD
was incorrect (pointing to the wrong repo, per the latest comment) but
did not actually check the PKGBUILD to see if that was true. I'll be
more through in my checks next time.
Regards,
Andrew
On Sun, Aug 3, 2014 at 2:08 PM, Johannes Löthberg
On 02/08, Andrew Crerar wrote:
Hi all,
I (andrewSC) would like to request ownership of yaourt-git (https://aur.archlinux.org/packages/yaourt-git/) as it's been flagged out-of-date for some time now.
Disregarding the fact that there seems to be nothing actually out of date with it, orphanship requests should be done from the AUR web interface now, under the 'File request' link on the package's page.
-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
How can VCS packages be out of date at all?
Client machines will only update a VCS package if: 1. The package maintainer updates a VCS package and gives it a newer version number than what is installed on a user's machine, and a user updates their packages. 2. The user explicitly requests that all VCS packages be updated. 3. The user explicitly re-installs a VCS package. The second only occurs if the user is using a package management tool that supports explicit upgrades of VCS packages, such as yaourt: [1] yaourt -Su --devel Pacman does not support such a VCS-specific upgrade option. Neither do many other package managers, such as pacaur (which I use). The third only occurs if users are following the development of upstream packages and manually decide to try out something new. [2] This is all to the best of my knowledge. I am unable to find relevant information that supports or denies my understanding either in the man pages for pacman [3] or pkgbuild [4]. Instead, I've simply drawn from my experiences maintaining packages and reading discussions here. [1] https://wiki.archlinux.org/index.php/Yaourt#Examples [2] https://mailman.archlinux.org/pipermail/aur-general/2014-June/029021.html [3] https://www.archlinux.org/pacman/pacman.8.html [4] https://www.archlinux.org/pacman/PKGBUILD.5.html — Jeremy "Ichimonji10" Audet
On 03/08, Jeremy Audet wrote:
How can VCS packages be out of date at all?
Client machines will only update a VCS package if:
Really, most ofthis is mostly irrelevant TBH. The AUR is a repository of PKGBUILDs. The official way of using the PKGBUILDs is manually with makepkg. Whether an AUR helper considers it out-of-date and needing updating is a completely different question to the AUR VCS package being out of date, so the only times an AUR VCS package is out-of-date is when it's broken in some way, like when the PKGBUILD standards change. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
Really, most ofthis is mostly irrelevant TBH.
This is a common point of confusion. Because of this, I think it is worth addressing and therefore relevant.
The official way of using the PKGBUILDs is manually with makepkg.
I suspect that the usual use case for interacting with the AUR is with an AUR helper. I think this qualifies it as subject matter that a capable package maintainer should have some familiarity with, even though this use case may be disagreeable to you personally.
the only times an AUR VCS package is out-of-date is when it's broken in some way
Assuming that AUR helpers are a common tool for interacting with the AUR, VCS packages in the AUR are out-of-date when their version number is... out-of-date. Finally, the situations that trigger a VCS package update should be identical whether a package is in the AUR or one of the more official repos. — Jeremy "Ichimonji10" Audet
Anyone using VCS packages from the AUR, should be following the package upstream and rebuilding it as they go. It is not meant for someone that is just casually using the package. The package version should be updated each time you build the package, specified in the pkgver() function. https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#The_pkgver.28.2... Because the version is changed whenever you rebuild it, it can't really be marked out of date, you should be tracking your packages and rebuilding them when new features are added or things are changed in order to test direct upstream packages. Daniel
Date: Sun, 3 Aug 2014 23:06:46 -0400 From: ichimonji10@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Package ownership change request for yaourt-git
Really, most ofthis is mostly irrelevant TBH.
This is a common point of confusion. Because of this, I think it is worth addressing and therefore relevant.
The official way of using the PKGBUILDs is manually with makepkg.
I suspect that the usual use case for interacting with the AUR is with an AUR helper. I think this qualifies it as subject matter that a capable package maintainer should have some familiarity with, even though this use case may be disagreeable to you personally.
the only times an AUR VCS package is out-of-date is when it's broken in some way
Assuming that AUR helpers are a common tool for interacting with the AUR, VCS packages in the AUR are out-of-date when their version number is... out-of-date.
Finally, the situations that trigger a VCS package update should be identical whether a package is in the AUR or one of the more official repos.
— Jeremy "Ichimonji10" Audet
On 03/08, Jeremy Audet wrote:
The official way of using the PKGBUILDs is manually with makepkg.
I suspect that the usual use case for interacting with the AUR is with an AUR helper. I think this qualifies it as subject matter that a capable package maintainer should have some familiarity with, even though this use case may be disagreeable to you personally.
If the PKGBUILD is sane and works, it works.
the only times an AUR VCS package is out-of-date is when it's broken in some way
Assuming that AUR helpers are a common tool for interacting with the AUR, VCS packages in the AUR are out-of-date when their version number is... out-of-date.
Which is never, because the AUR doesn't contain built packages, only PKGBUILDs which are used to build packages.
Finally, the situations that trigger a VCS package update should be identical whether a package is in the AUR or one of the more official repos.
That's never going to happen unless Arch moves to become a from-source-distro instead of a binary one. PKGBUILDs are recipies that are used to build packages. Until the package is actually build it doesn't have a pkgversion. Repo packages are built packages which are build from PKGBUILDs, and pacman will never build packages. That's makepkg's job, not the package manager's. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On 2014-08-03 22:06, Jeremy Audet wrote:
the only times an AUR VCS package is out-of-date is when it's broken in some way
Assuming that AUR helpers are a common tool for interacting with the AUR, VCS packages in the AUR are out-of-date when their version number is... out-of-date.
Finally, the situations that trigger a VCS package update should be identical whether a package is in the AUR or one of the more official repos.
— Jeremy "Ichimonji10" Audet
This is totally and completely wrong. The version number changes on each commit, are you claiming that the PKGBUILD needs updated for each commit? Even if you're talking about a major/minor version change, just rebuild the package and it updates. That's your responsibility, the package isn't out of date unless it doesn't build because of upstream changes.
Anyone using VCS packages from the AUR, should be following the package upstream and rebuilding it as they go.
Aha. This gets to the heart of things. I've been assuming that many VCS package users will install a VCS package and henceforth rely upon the package maintainer to update the VCS package on a regular basis, therefore triggering a user's package manager to update that VCS package. If it is assumed that all VCS package users explicitly update all of their VCS packages, then yes, never updating a VCS package makes sense. Thanks for the explanation.
Johannes Löthberg ...
Mmhmm. I well understand the difference between PKGBUILDs and packages, the fact that makepkg uses the `pkgver` function in VCS packages, and so on.
The version number changes on each commit, are you claiming that the PKGBUILD needs updated for each commit?
That depends on the use case. Now that Daniel has explained the officially supported use case to me, my answer is "no", VCS PKGBUILDs do not need to be updated for each commit.
just rebuild the package and it updates. That's your responsibility
Again, I did not realize that this was the only officially supported use case. — Jeremy "Ichimonji10" Audet
participants (6)
-
Andrew Crerar
-
Daniel Wallace
-
Doug Newgard
-
Jeremy Audet
-
Johannes Löthberg
-
Stefan Husmann