You are not logged in.

#1 2018-07-21 13:32:47

momu
Member
Registered: 2017-10-14
Posts: 137

[SOLVED]xcursor-capitaine is always available for update

I use aurget to download/update/install/etc. AUR packages. Whenever I run

aurget -Syu

package xcursor-capitaine is always availabe for update (even if I updated it a moment ago!).

How to fix this? Does the problem lie in the aurget itself or in the package?

Last edited by momu (2018-07-21 20:00:17)

Offline

#2 2018-07-21 13:44:34

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

Re: [SOLVED]xcursor-capitaine is always available for update

There are problems with the package.  It pulls from git master, but the package name does not end with the appropriate -git suffix.

But given that is actually is a VCS PKGBUILD, aurget is properly determining that it can indeed always be updated depeneding on what 'update' actually means.  Aurget should retreive the source and run the pkgver function on every invocation.  Then it should build and install the new package only if there actually is a new pkgver.  From a quick look at the code, I beleive it depends on makepkg for the latter, and this will only work if you save the build directories of devel packages which aurget seems to have an option for.

Last edited by Trilby (2018-07-21 13:52:48)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2018-07-21 13:47:55

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

There's also a problem with how the maintainer made the pkgver. It's gone from r2.14.xxx to r2.1.xxx, which is what's confused your helper. Packaging problem.

Offline

#4 2018-07-21 13:48:18

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Trilby wrote:

There are problems with the package.  It pulls from git master, but the package name does not end with the appropriate -git suffix.

But given that is actually is a VCS PKGBUILD, aurget is properly determining that it can indeed always be updated depeneding on what 'update' actually means.  Aurget should retreive the source and run the pkgver function on every invocation.  Then it should build and install the new package only if there actually is a new pkgver.

aurget builds and installs xcursor-capitaine every time I run aurget -Syu. And please explain what 'update' means if a package always can be upgraded.

Last edited by momu (2018-07-21 13:50:59)

Offline

#5 2018-07-21 13:58:12

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

Re: [SOLVED]xcursor-capitaine is always available for update

I was asking you what update meant in this context.  On every single run of an aur helper, every single VCS package must be assumed to have updates available until/unless the current source is retreived, the pkgver function is run, and the new pkgver is found to be the same as the installed one.  There is no way to know just from the AUR web interface or rpc whether or not a VCS package can be updated.

So, if 'update' means that on every run your helper pulls the most recent code from xcursor-capitaine's upstream git source, and does some running of makepkg on it, then this is perfectly normal and necessary.

If 'update'  means that on top of the above, it also rebuilds and reinstalls the package every single time, then this is not necessary, but perhaps not unexpected either as the ability to abort the build after detecting that the new pkgver is the same as what is installed depends on several criteria.  It is not clear whether those criteria hold in your case.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2018-07-21 14:04:56

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

And again, the issue is with the pkgver the maintainer used here.

Offline

#7 2018-07-21 14:12:01

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Trilby wrote:

I was asking you what update meant in this context.  On every single run of an aur helper, every single VCS package must be assumed to have updates available until/unless the current source is retreived, the pkgver function is run, and the new pkgver is found to be the same as the installed one.  There is no way to know just from the AUR web interface or rpc whether or not a VCS package can be updated.

So, if 'update' means that on every run your helper pulls the most recent code from xcursor-capitaine's upstream git source, and does some running of makepkg on it, then this is perfectly normal and necessary.

If 'update'  means that on top of the above, it also rebuilds and reinstalls the package every single time, then this is not necessary, but perhaps not unexpected either as the ability to abort the build after detecting that the new pkgver is the same as what is installed depends on several criteria.  It is not clear whether those criteria hold in your case.

Thank you for answering.

I don't know how aurget works for sure, but it seems that this is the general procedure:
1. Checks which packages are available for update.
2. Downloads them.
3. Builds them.
4. Installs them.
Steps 2-4 are performed in one turn for each package, i.e. aurget downloads, builds and installs a package before proceeding to do the same with next package.
All packages that pass step 1 must go on with steps 2-4.

Offline

#8 2018-07-21 14:12:51

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Scimmia wrote:

And again, the issue is with the pkgver the maintainer used here.

Can we somehow note the maintainer to fix that?

Last edited by momu (2018-07-21 14:17:34)

Offline

#9 2018-07-21 14:24:13

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

Re: [SOLVED]xcursor-capitaine is always available for update

There's a comments section on the aur page you already linked to.

But the change in version numbering was 8 months ago.  That would not explain why two runs of your aur helper within the last 8 months would both indicate that an update was available.

Rather that your steps in post #7 have a lot of "magic" in step 1.  There is no practical way to check whether a VCS package has an update other than proceeding through step 2 and part of step 3.  So if step 2 locks it into all the other steps (big if), then yes, xcursor-capitaine should be rebuilt and reinstalled on every run of your helper.

EDIT: ah, wait.  I see what Scimmia is saying.  If (another big if) aurget is incorrectly determining the version number for a VCS PKGBUILD and just believing what it gets from the rpc, then yes, it could keep seeing the currently installed version as older.  But that is a completely broken way of handling VCS packages, and from my quick reading of aurget's code, that is not what it is doing - EDIT 2: wait, it actually is.  I thought aurget was checking the source url for 'git' and similar in it's "is_devel" function, but it's just checking the package name.  As this package is incorrectly named it would not be detected as a devel package by aurget - so yes, the current problem is due to 2 packaging issues: an incorrect name lacking -git, and pkgver function that will not work with upstreams naming conventions.

Last edited by Trilby (2018-07-21 14:29:20)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2018-07-21 14:28:31

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

...except it's not being handled as a VCS package. The current version is simply listed as older that the pkgver that's listed in the AUR.

Offline

#11 2018-07-21 14:37:55

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Trilby wrote:

There's a comments section on the aur page you already linked to.

I know, but I don't see an option to leave a comment.

Trilby wrote:

Rather that your steps in post #7 have a lot of "magic" in step 1.  There is no practical way to check whether a VCS package has an update other than proceeding through step 2 and part of step 3.  So if step 2 locks it into all the other steps (big if), then yes, xcursor-capitaine should be rebuilt and reinstalled on every run of your helper.

Yeah, that's strange. It's like aurget keeps a list of packages like pacman.

Offline

#12 2018-07-21 14:49:12

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

Log in, then you can comment.

Edit: and for the last time, nothing is strange here. The maintainer screwed up on versioning and the version listed in the AUR is newer than the current version. Nothing mystical, a very straight-forward version check.

Last edited by Scimmia (2018-07-21 14:50:18)

Offline

#13 2018-07-21 14:53:21

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Scimmia wrote:

Log in, then you can comment.

I can't log in.  I get "Bad username or password." even though I used my username and password I use to log in Forums.

Last edited by momu (2018-07-21 14:53:38)

Offline

#14 2018-07-21 14:56:57

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

It's the AUR, not the forums. The user databases have no thing to do with each other.

Offline

#15 2018-07-21 15:00:09

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Scimmia wrote:

It's the AUR, not the forums. The user databases have no thing to do with each other.

Ohhh... so I need another account. Ok, no problem.

Offline

#16 2018-07-21 15:02:45

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

Re: [SOLVED]xcursor-capitaine is always available for update

In addition to fixing the package name to have a -git suffix, the maintainer should also - in this case - add an epoch number, then use a pkgver function that will work better with upstream's version naming in the future.

I'd consider actually just trimming the initial 'r' from the upstream version, then it should work nicely.  In fact, in that case, no epoch number would even be needed yet.  So the current version would be 2.1.r2.g...

The only downside would be if/when upstream drops the initial 'r' themselves and restarts at a low number.  But the maintainer can check with upstream on whether this is likely, and even then could just add an epoch number at that point in the future.

Last edited by Trilby (2018-07-21 15:03:16)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#17 2018-07-21 15:05:01

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Done. When (s)he fixes it I'll mark this thread as [SOLVED].

Last edited by momu (2018-07-21 15:07:13)

Offline

#18 2018-07-21 18:02:16

limadm
Member
Registered: 2018-07-21
Posts: 2

Re: [SOLVED]xcursor-capitaine is always available for update

Hi, momu!
Thanks for noticing that. Upstream changed the tag numbering scheme, for which pkgver was not prepared.
Also, I didn't care about using a -git prefix, because there was an older capitaine-cursors package (which is more popular).
So, I split this package in two, xcursor-capitaine 2.1-1 and xcursor-capitaine-git 2.1.r2.xxxcommit-1 which maps its tags/revisions to a monotonic package version.

Offline

#19 2018-07-21 18:45:50

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SOLVED]xcursor-capitaine is always available for update

Does pacman not consider r2.14.gfbb3887 > 2.1 meaning the pkgver with the new release has decreased?

Offline

#20 2018-07-21 18:52:20

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

No, a number is greater than a letter

Offline

#21 2018-07-21 18:58:24

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

Re: [SOLVED]xcursor-capitaine is always available for update

loqs wrote:

Does pacman not consider r2.14.gfbb3887 > 2.1 meaning the pkgver with the new release has decreased?

No, it doesn't:

$ python
> import pyalpm
> pyalpm.vercmp('r2.14','2.1')
-1
> pyalpm.vercmp('2','3')
-1

2.1 is an actual version, r2.14 is a revision number without a version, thus (in my mind, and in the apparent result of alpm vercmp) the version is 0.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#22 2018-07-21 19:07:55

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

limadm wrote:

Hi, momu!
Thanks for noticing that. Upstream changed the tag numbering scheme, for which pkgver was not prepared.
Also, I didn't care about using a -git prefix, because there was an older capitaine-cursors package (which is more popular).
So, I split this package in two, xcursor-capitaine 2.1-1 and xcursor-capitaine-git 2.1.r2.xxxcommit-1 which maps its tags/revisions to a monotonic package version.

Hi, limadm (again). Thank you for fixing this. If I understood everything correctly, packages xcursor-capitaine and xcursor-capitaine-git are identical in everything except that the latter one contains the fix. Please, confirm is that true or not.

Offline

#23 2018-07-21 19:32:10

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: [SOLVED]xcursor-capitaine is always available for update

No, one builds from the stable release, one builds from git HEAD.

Offline

#24 2018-07-21 19:56:00

momu
Member
Registered: 2017-10-14
Posts: 137

Re: [SOLVED]xcursor-capitaine is always available for update

Scimmia wrote:

No, one builds from the stable release, one builds from git HEAD.

Ok. I suspected that but wanted to be sure.

limadm, please write here when you fix the package.

Offline

#25 2018-07-21 19:56:42

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

Re: [SOLVED]xcursor-capitaine is always available for update

It has been fixed - is there still a problem?


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB