You are not logged in.

#1 2020-10-18 20:05:50

MountainX
Member
Registered: 2016-02-08
Posts: 262

[SOLVED] Catch-22 for pkgver VCS autobump of version number

I have two questions about VCS package versioning. I've been reading up on it, including these articles, but I still have confusion:

VCS package guidelines - ArchWiki

PKGBUILD-vcs.proto « proto - pacman.git - The official pacman repository

Talk:VCS package guidelines - ArchWiki

"I'm suggesting the information whether a package needs to be rebuilt is transported in the pkgver." This is really the heart of the matter. This is completely and totally wrong for VCS packages.

When making my own packages for a private repo, if the pkgver is not updated in the PKGBUILD, operations like `makepkg --packagelist` do not work as expected. Then I cannot do thiings like this in my scripts: [EDIT: ayekat answered this part of my question. Skip to second half of my question below.]

newpkg=$(makepkg --packagelist);
gpg --yes --detach-sign "$newpkg";
namcap -i "$newpkg";

What is the recommended solution for a script to determine the version of a built package if the PKGBUILD pkgver=XXX value cannot be used?

Second part of question:

I've been using the pkgver autobump feature. (I'm using git.) My version numbers are like this:

r36.6d2094e
r41.39481aa
r42.146eae2

But the version autobump feature is causing me an endless loop of version increments. For example, I make a code change and commit it. Then I build the package and it gets a new version number. I have to save this PKGBUILD with the incremented version in order for my scripts to work as expected (see above). But that forces me to commit the updated PKGBUILD file. This commit then results in a version autobump, and the start of an endless loop.

It seems to me, that if I expect to automate my builds, including signing packages, etc., that I have to abandon VCS versioning, autobump, etc., and just manually version my packages. But that means I have to remember to increment the version myself, and that "little" thing is presumably why the pkgver autobump was originally implemented for VCS packages.

I'm confused about how to proceed. I know I'm not the only person managing my own Arch packages with VCS. What is the accepted best practice for my situation?

Last edited by MountainX (2020-10-18 23:10:58)

Offline

#2 2020-10-18 20:36:49

ayekat
Member
Registered: 2011-01-17
Posts: 1,409
Website

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

MountainX wrote:

When making my own packages for a private repo, if the pkgver is not updated in the PKGBUILD, operations like `makepkg --packagelist` do not work as expected.

Could you please elaborate on this?
From what I understood, you want to run --packagelist after a package is built, no? Otherwise things like signing and running namcap don't make much sense there.
Given that makepkg updates pkgver when building a VCS package, a subsequent --packagelist should output the right version information, no?

I also don't quite see the relevance of the quote pulled from that Wiki page discussion - AFAICT that was a different issue.


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#3 2020-10-18 20:47:48

MountainX
Member
Registered: 2016-02-08
Posts: 262

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

ayekat wrote:
MountainX wrote:

When making my own packages for a private repo, if the pkgver is not updated in the PKGBUILD, operations like `makepkg --packagelist` do not work as expected.

From what I understood, you want to run --packagelist after a package is built, no? Otherwise things like signing and running namcap don't make much sense there.

Yes, correct. I did have an error in my script where `makepkg --packagelist` was called too early. Thanks for the reminder. This resolves the first half of my question.

ayekat wrote:

Given that makepkg updates pkgver when building a VCS package, a subsequent --packagelist should output the right version information, no?

I will get a version mismatch -- unless I save the locally updated version of PKGBUILD, which then causes my local repo to not be in sync with the one I pull from due to the changed PKGBUILD file. (This leads to the 2nd half of my question, below.) Here's an example of what I'm seeing right now, after building a package, because I did not save the PKGBUILD file that was changed by makepkg.

printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
r42.146eae2

makepkg --packagelist
/path/to/mypackage-r41.39481aa-1-any.pkg.tar.zst

To avoid confusing myself, I am thinking about never using 'makepkg --packagelist' and always using my own function similar to pkgver() that uses 'git rev-list'.

ayekat wrote:

I also don't quite see the relevance of the quote pulled from that Wiki page discussion - AFAICT that was a different issue.

OK. It wasn't clear to me that it was a different issue. I have been reading everything I could find on VCS package versioning and not all of it makes sense to me yet (due to lack of experience).

Regarding the 2nd part of my question how should PKGBUILD files be managed in VCS? I check mine into the repo with the code. Makepkg autobumps the version number, after I build, which seems to force me to commit and push the updated PKGBUILD file. But that leads to the endless loop of version-number related updates. I do want my PKGBUILD files to be under VCS, but I guess the way I'm going about that is wrong. What is the right way?

Another related issue I face is that I have a script that loops through all my package source code directories and checks to see if any have outstanding changes that need to be committed. But having modified PKGBUILD files causes my script to detect changes not staged for commit. As said, I don't want to ignore my PKGBUILD files particularly right now because I'm still learning how to write them and I am frequently making meaningful changes to them.

Last edited by MountainX (2020-10-18 21:43:22)

Offline

#4 2020-10-18 22:01:38

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,768

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

I'm a little bit confused why modifying the PKGBUILD stored outside of the source code it lists in source=() would result in the git repo that is then cloned from git, to report new commits?


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2020-10-18 22:08:10

MountainX
Member
Registered: 2016-02-08
Posts: 262

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

eschwartz wrote:

I'm a little bit confused why modifying the PKGBUILD stored outside of the source code it lists in source=() would result in the git repo that is then cloned from git, to report new commits?

For my personal projects, the PKGBUILD is stored in the same repo listed in source=(). It felt natural and organized to keep the PKGBUILD for a project with the rest of the code for that project. EDIT: Obviously, I do need the PKGBUILD file to be in the directory in order to build the package. If the PKGBUILD is not in the same repo as the source code, I will need to find a convenient method for managing PKGBUILD files that I'm editing frequently as I learn about packaging.

How would you suggest doing it?

Last edited by MountainX (2020-10-18 22:13:29)

Offline

#6 2020-10-18 22:14:12

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,768

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

Typically a PKGBUILD would be e.g. uploaded to the AUR and download the git repo from github. The AUR doesn't permit uploading source code directly, and the PKGBUILD format doesn't permit source=() files with directory paths.

The pkgver() autobump functionality is tied to the idea that the provider of the PKGBUILD does not know the current upstream version, and isn't intended or designed to self-referentially determine its own version. Hence the circular issue you noted.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2020-10-18 22:35:15

MountainX
Member
Registered: 2016-02-08
Posts: 262

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

eschwartz wrote:

The pkgver() autobump functionality is tied to the idea that the provider of the PKGBUILD does not know the current upstream version, and isn't intended or designed to self-referentially determine its own version. Hence the circular issue you noted.

Thank you for taking the time to answer. It sounds like the right approach in my current situation (and for my personal packages) is to not use the pkgver() autobump functionality.

Offline

#8 2020-10-18 22:50:44

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,768

Re: [SOLVED] Catch-22 for pkgver VCS autobump of version number

Probably. You could just increment a number every time you modify the sources.

Other packaging systems, like Debian, do something similar, where (I think) the version number comes from the changelog file and you change the version by adding changelog entries.

(Debian packaging is also required to live in the debian/ subdirectory of your source code.)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB