You are not logged in.
I thought so to, until this which completely contradicts that: https://bbs.archlinux.org/viewtopic.php … 5#p1291455
Hence my confusion.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I thought so to, until this which completely contradicts that: https://bbs.archlinux.org/viewtopic.php … 5#p1291455
Hence my confusion.
VCS PKGBUILDs are not static, but the solution to this issue depends on ones updating habits:
Maybe I should not re-use VCS PKGBUILDs, but maybe makepkg should not edit pkgversion and pkgrel ?
and / or some RFCs and patches.
Offline
VCS PKGBUILDs are not static
What does that mean? Of course they are. PKGBUILDs don't change on their own while hanging out in the AUR.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
makepkg auto-updates VCS PKGBUILDs https://wiki.archlinux.org/index.php/VC … 9_function , it doesn't update non-VCS ones.
Offline
But only when you run makepkg on them - and this only revises the version numbers! They don't change in the AUR. So to detect if the PKGBUILD in the aur has changed it is NO different than non-vcs PKGBUILDS.
If one is asking whether the maintainer has changed some functionality of the PKGBUILD, then the answer is that it is exactly the same as a non-vcs package.
If one is asking whether there is a new version of the source code in the vcs system (eg, git) that is a different question, but you *don't* need to redownload the PKGBUILD, the old one will do just fine.
This is my point, which question is being asked here?
Last edited by Trilby (2013-06-23 18:52:38)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
But only when you run makepkg on them - and this only revises the version numbers! They don't change in the AUR. So to detect if the PKGBUILD in the aur has changed it is NO different than non-vcs PKGBUILDS.
If one is asking whether the maintainer has changed some functionality of the PKGBUILD, then the answer is that it is exactly the same as a non-vcs package.
No this is not the same. I think karol understood what I mean, but you did not.
How do you know if your package is outdated ? You compare your local version to the one on the repo/AUR
. How do you do know if the version (in case of VCS package) you installed is not the same as it was when you downloaded it ? How do you remember the inital verison ? You cannot.
Last edited by maxi_jac (2013-06-23 19:12:02)
Offline
The easy solution is to always get tAURballs from the AUR and not re-use the PKGBUILDs you've already downloaded, but you don't like doing it this way.
If maintainers rebuild the package when making some PKGBUILD changes, it should have the latest package version, although a lazy maintainer might skip the testing of the new PKGBUILD and leave the old pkgver.
Offline
In this case you don't need to download the PKGBUILD from the aur - it won't get you any information that you don't have in the local PKGBUILD.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
In this case you don't need to download the PKGBUILD from the aur - it won't get you any information that you don't have in the local PKGBUILD.
If the maintainer changed the configure part of the PKGBUILD you get new info ...
Offline
YES, but that's my point - that is the other question, and is exactly the same as non-vcs PKGBUILDS.
If the PKGBUILD has been rewritten by the author to change the build or package functions, you'll need the new PKGBUILD from the aur - this is true for vcs and non-vcs packages, so the fact that they are vcs is irrelevant. If the PKGBUILD in the aur has not been revised in this way, you do not need to download a PKGBUILD to get the new version number - the local PKGBUILD will work just as well.
Last edited by Trilby (2013-06-23 19:47:07)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
If the PKGBUILD has been rewritten by the author to change the build or package functions, you'll need the new PKGBUILD from the aur
How do you know it was?
Offline
OK, Karol definitely got my point.
YES, but that's my point - that is the other question, and is exactly the same as non-vcs PKGBUILDS.
If the PKGBUILD has been rewritten by the author to change the build or package functions, you'll need the new PKGBUILD from the aur - this is true for vcs and non-vcs packages, so the fact that they are vcs is irrelevant. If the PKGBUILD in the aur has not been revised in this way, you do not need to download a PKGBUILD to get the new version number - the local PKGBUILD will work just as well.
Why do say this is true for non VCS ? It is not.
Non VCS packages have a real version and pkgrel strongly matching the PKGBUILD they use and the version they produce.
This absolutely not the same.
package foo has v1.1 pkgrel 2, you build it anytime you want it will be foo-1.1-2
package foo-git with version 12345 and pkgrel 2, if you build it today you may get foo-git-12346-1 and next day foo-git-12347-1
Offline
@Karol, Oh this is ridiculous. That's exactly what I responded to here: https://bbs.archlinux.org/viewtopic.php … 5#p1291425
The point is however you go about determining whether the PKGBUILD in the aur has been updated, the fact that it is a vcs package is irrelevant: the steps will be exactly the same for a vcs or non vcs PKGBUILD if you want to know whether the PKGBUILD has been revised.
If the PKGBUILD has not been revised, but you want to check if the source has been updated, then you do not need a new PKGBUILD.
Last edited by Trilby (2013-06-23 20:11:49)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
package foo-git with version 12345 and pkgrel 2, if you build it today you may get foo-git-12346-1 and next day foo-git-12347-1
Yes, but you don't need a new PKGBUILD every time you rebuild it - you can use the same PKGBUILD each of those days.
The only time you need to download the new PKGBUILD is when the PKGBUILD itself changes (build or package functions) - and this is true for non vcs packages and vcs packages. If there is a new way of configuring or building the package, you need the new PKGBUILD - if there has not been such a change, you don't need it - the local PKGBUILD will do the same.
Last edited by Trilby (2013-06-23 20:17:28)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
No, Trilby, for a non-VCS package it's enough to look at the pkgver & pkgrel.
If I built a VCS package locally its pkgrel is reset to 1 and its pkgver gets bumped, it's not the same as the pkgver & pkgrel of the package that's currently in the AUR, but the PKGBUILD might be the same.
Offline
And if the PKGBUILD is the same you dont need to download another copy of the same PKGBUILD, right?
That was the original question: does one need to download the PKGBUILD from the aur to check if the vcs source has changed: no, just run makepkg on the local PKGBUILD.
Also version and release are enough for VCS packages too:
If your local version is equal to or ahead of the AUR package, then you don't need to download the PKGBUILD from the aur: use the local copy.
If your local version is behind the AUR package, then - and only then - do you need to download the PKGBUILD (just like with non-vcs packages).
Here's a concrete example: https://aur.archlinux.org/packages/alopex-git/
alopex-git is listed as 2.229 in the aur. But the vcs source is at commit 281 (2.281). If an alopex user has a local version higher than 2.229, they know that I have not changed the PKGBUILD since they last built. If I changed the PKGBUILD right now, the aur page would then list the version as 2.281 (unless this coincided with a git commit, then it would be 2.282). Alopex users would then know that since their local version number was behind what was listed in the AUR that the PKGBUILD had changed (or at least that the source tarball was rebuilt). If they do not see such a change on the aur-page version number, then they can continue to get alopex updates by running makepkg on a copy of the PKGBUILD they downloaded weeks ago.
What's different here from non-vcs packages for determining if you need to download a new PKGBUILD? In either case, if the aur-page version number is ahead of what you have locally, you need the new PKGBUILD, if not, you don't.
With VCS packages, you need to check the vcs source (with makepkg for example) to find if updates are available, but downloading a new PKGBUILD will not help this process - the previous PKGBUILD will do the exact same thing.
Last edited by Trilby (2013-06-23 20:28:35)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
If your local version is equal to or ahead of the AUR package, then you don't need to download the PKGBUILD from the aur: use the local copy.
Nope.
You can make a note which pkgrel you downloaded or just download the tAURball, but you can't tell if you have an up-to-date PKGBUILD just by looking at the numbers.
Offline
Yes, I just gave a concrete example how and why. Feel free to give an example where this wouldn't work.
You can't tell if you have the most up-to-date package (as there could be new git commits for example) but you definitely can tell if you have the most up-to-date PKGBUILD.
Last edited by Trilby (2013-06-23 20:30:34)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Yes, I just gave a concrete example how and why. Feel free to give an example where this wouldn't work.
https://wiki.archlinux.org/index.php/VC … Guidelines
If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the pkgrel is mandatory. Touching the pkgver isn't.
Offline
Then the package release would increase.
I don't know why one would use holdver, but without that any rebuild of the source tarball will increase the version number to higher than what users currently have. If a packager does use holder, then they must increase the release number.
So package version and release number *are* sufficient.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Then the package release would increase.
Yup.
As I built the package locally, the pkgrel for my package is at 1, the package in the AUR has a lower pkgver but higher pkgrel.
I might have an up-to-date PKGBUILD or not, no way to tell from just pkgver and pkgrel.
Offline
I don't get what you are not understanding Trillby.
Anyways, the answer to my question is that either I'm not using the tools as intended or it's a usability bug or a missing feature.
Offline
Well now I see what I was not getting. Pairing a local reset of a pkgrel while allowing authors to use this as the only indication of a change is news to me.
I'd argue that if a vcs PKGBUILD is rewritten, the pkgver should not be held with holdver - what purpose does that serve but to lead to this confusion?
As long as packagers *don't* specifically use the --holdver flag when they may the aur tarball, this would not be an issue at all (and then everything I argued adamantly would be true). It seems the only purpose of holdver is to obscure this information.
*Bad wolf impression: I'll huff and I'll puff and I'll ... learn something new when Karol proves me wrong*
Last edited by Trilby (2013-06-23 20:53:29)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
If pkgrel isn't reset to 1 with a new pkgver, as it is being done with non-VCS packages, then Trilby is right.
Edit: Just as I was about to give up, we seem to arrive on same page :-)
Last edited by karol (2013-06-23 20:58:07)
Offline
Perhaps then we can work towards a proposal for a revision to give to the 'powers that be'.
There has to be some reason to use holdver and allow for not bumping the version number when uploading a new PKGBUILD ... I would hope there is some reason. Does anyone know why that is an option?
I can imagine in cases where someone found a minor typo in the package description string, or some such. Something that would not affect operability and would thus not require users to get the new PKGBUILD, but the author felt compelled to fix it. But if this were elaborated as the only suitable use for using --holdver, then the version numbers *would* be a reliable indicator of when one needed the new PKGBUILD for proper function.
Last edited by Trilby (2013-06-23 21:02:22)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline