You are not logged in.

#26 2013-06-23 18:18:32

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#27 2013-06-23 18:23:31

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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:

maxi_jac wrote:

Maybe I should not re-use VCS PKGBUILDs, but maybe makepkg should not edit pkgversion and pkgrel ?

and / or some RFCs and patches.

Offline

#28 2013-06-23 18:32:56

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

karol wrote:

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

#29 2013-06-23 18:45:06

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

makepkg auto-updates VCS PKGBUILDs https://wiki.archlinux.org/index.php/VC … 9_function , it doesn't update non-VCS ones.

Offline

#30 2013-06-23 18:48:58

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#31 2013-06-23 19:09:53

maxi_jac
Member
From: France
Registered: 2008-08-02
Posts: 72

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#32 2013-06-23 19:20:31

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

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

#33 2013-06-23 19:36:04

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#34 2013-06-23 19:38:54

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#35 2013-06-23 19:42:41

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#36 2013-06-23 20:07:38

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#37 2013-06-23 20:10:20

maxi_jac
Member
From: France
Registered: 2008-08-02
Posts: 72

Re: Comparing VCS PKGBUILD versions

OK, Karol definitely got my point.

Trilby wrote:

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

#38 2013-06-23 20:10:43

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

@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

#39 2013-06-23 20:14:38

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

maxi_jac wrote:

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

#40 2013-06-23 20:15:37

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

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

#41 2013-06-23 20:18:53

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#42 2013-06-23 20:26:59

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#43 2013-06-23 20:29:15

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#44 2013-06-23 20:30:59

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#45 2013-06-23 20:34:47

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#46 2013-06-23 20:41:38

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

Trilby wrote:

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

#47 2013-06-23 20:46:02

maxi_jac
Member
From: France
Registered: 2008-08-02
Posts: 72

Re: Comparing VCS PKGBUILD versions

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

#48 2013-06-23 20:50:43

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

#49 2013-06-23 20:51:19

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Comparing VCS PKGBUILD versions

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

#50 2013-06-23 21:00:17

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Comparing VCS PKGBUILD versions

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

Board footer

Powered by FluxBB