Consistent pkgver in device packages

changed the description

By f_ on 2024-02-19T12:41:17

There was a previous attempt to fix that, by using semantic versioning instead: #1717 (closed) However, the proposal was rejected. Maybe we should try again, but with another technical proposal? The easiest to implement (that was also proposed before) is to have a single number. But not sure if there are some people still against it.

By Pablo Correa Gomez on 2024-02-21T18:32:21

Here's what I've personally settled on for device packages I maintain:

Use only whole integers for pkgver
if checksums were changed, then pkgver++ and set pkgrel=0
else pkgrel++, pkgver stays the same

By clayton craft on 2024-02-21T18:32:21

That's already better than what we have now. But maybe forcing pkgrel to always 0 is helpful for device maintainers (they would not have to think at all as sicelo mentions). And probably quite easy to check on CI compared to everything else.

By Pablo Correa Gomez on 2024-02-22T20:54:49

+1 for enforcing proposed "simple increment" - for device packages there is no reason whatsoever to use semver: there is no "api", every change is a meaningful change that will probably change the device state in some way, and people just bump "patch" bit all the time anyway if a device has semver numbering since no one understand or is just scared to be the one to bump "rel"...

I had a bit of fun with the semver things earlier in !4826 where I had to add extra scripting to un-semver the version bump...

By Nikita Travkin on 2024-02-27T14:33:46

But not sure if there are some people still against it.

I would love to hear an answer to: What (real) problem is the 'inconsistency' causing?

And yes, I totally agree with the final decision from #1717 (closed) and I personally find it still valid.

By Sicelo on 2024-02-19T20:32:50

The problem with inconsistency is inconsistency itself. From a maintainer perspective, it's brain-power spent on reviewing MRs to try understand if the pkgver increase makes any sense.

And yes, I totally agree with the final decision from #1717 (closed) and I personally find it still valid.

The decision there was to not use semver, not that things should remain inconsistent forever. Though maybe we discuss it again, and reach the same conclusion, who knows.

By Pablo Correa Gomez on 2024-02-21T18:29:50

From a maintainer perspective, it's brain-power spent on reviewing MRs to try understand if the pkgver increase makes any sense.

It always makes sense, of course. It is dictated by apk, is it not? Somewhere in Alpine docs (or is it pmOS?) it is stated that if source files are touched, pkgver shall be bumped, and if it's only the packaging, then pkgrel is bumped. I would like to think that's a simple enough concept.

As a result, I see absolutely no reason for a maintainer to spend any brain power on the pkgver (or its delta) at all. Hence the still the unanswered question ... What (real) problem has been caused by the inconsistency and lack of a policy regarding versioning?

By Sicelo on 2024-02-19T21:14:32

It always makes sense, of course. It is dictated by apk, is it not? Somewhere in Alpine docs (or is it pmOS?) it is stated that if source files are touched, pkgver shall be bumped, and if it's only the packaging, then pkgrel is bumped. I would like to think that's a simple enough concept.

It's simple enough, but not everyone follows it unless reminded (let alone knows about it), which means more review questions that really don't amount to much meaningful change once resolved.

As a result, I see absolutely no reason for a maintainer to spend any brain power on the pkgver (or its delta) at all. Hence the still the unanswered question ... What (real) problem has been caused by the inconsistency and lack of a policy regarding versioning?

I think ideally we would come up with a system that is obvious and doesn't require linking to docs or reminding. Personally I would be in favour of only having a pkgver that gets bumped, but I don't think we can remove the pkgrel property from packages. It would have to be proposed upstream.

By Newbyte on 2024-02-19T21:14:32

So we discussed a bit in the meeting today, taking all this input into consideration. Our ideal solution for this would be:

Keep using pkgver and pkgrel as recommended in the wiki and as everybody knows how to do from here and Alpine (if checksums change, update pkgver, else pkgrel)
Force pkgver to be an ever-increasing integer. (Personsal Joke: if our problem is device-oneplus-enchilada=34561-r3 we might as well die of success)

To achieve this we should:

Update pmbootstrap newapkbuild command to generate a pkgver=1 instead of pkgver=0.1
Document it in the wiki
Add CI that at least checks that all pkgvers are integers. Might mean scripting changes over the whole repo (hopefully @TravMurav experience can help here) to update current packages.
(Optional) Add CI that check "if checksums change, update pkgver, else pkgrel". Should be possible to disable for the cases were there is a legit use-case.

@funderscore or anybody else, what do you think? Do you have the motivation to work on this?

By Pablo Correa Gomez on 2024-04-02T11:03:36

FWIW what I used to bump semver packages to n+1th increment:

... | xargs -i sh -c \
	'sed -i "s/pkgver=.*/pkgver=$(( $(grep -m1 pkgver {} | cut -b8- | sed "s/\..*//") + 1))/" {}'

This is just a quick hack but what it does is it replaces pkgver with an evaluation of "pkgver value until the dot + 1"

For CI could as well just check for the dot in the line:

$ grep -qe "^pkgver.*\..*" device-samsung-gt510/APKBUILD ; echo $?
1
$ grep -qe "^pkgver.*\..*" device-pine64-pinephonepro/APKBUILD ; echo $?
0

By Nikita Travkin on 2024-03-01T05:40:35

what do you think? Do you have the motivation to work on this

Ack. I can work on that.

By f_ on 2024-03-01T13:19:25

Update pmbootstrap newapkbuild command to generate a pkgver=1 instead of pkgver=0.1

https://gitlab.com/postmarketOS/pmbootstrap/-/merge_requests/2275

By Newbyte on 2024-03-11T10:55:03

For reference, this:

grep -e "^pkgver.*\..*" device/*/device-*/APKBUILD | less

lists out all device packages with a dot in the pkgver

By f_ on 2024-04-02T10:53:36

mentioned in commit pmbootstrap@caa43675

By Newbyte on 2024-03-11T10:53:59

mentioned in merge request pmbootstrap!2275 (merged)

By Newbyte on 2024-03-11T10:54:35

mentioned in commit pmbootstrap@c6e8a89e

By Newbyte on 2024-03-11T18:54:55

mentioned in commit 8b92bd1d

By f_ on 2024-04-02T10:57:00

changed the description

By f_ on 2024-04-02T11:00:17

mentioned in commit 44b9db82

By f_ on 2024-04-02T12:16:09

changed the description

By clayton craft on 2024-04-02T22:02:09

marked this issue as related to #1717 (closed)

By Pablo Correa Gomez on 2024-04-17T14:49:17

marked the checklist item Document it in the wiki as completed

By Pablo Correa Gomez on 2024-04-17T14:55:39

changed the description

By Pablo Correa Gomez on 2024-04-17T14:56:21

marked the checklist item Add CI that at least checks that all pkgvers are integers. as completed

By Pablo Correa Gomez on 2024-05-15T14:57:41

marked the checklist item Update existing device packages as completed

By Pablo Correa Gomez on 2024-05-15T14:57:42

marked the checklist item (Optional) Add CI that check "if checksums change, update pkgver, else pkgrel". Should be possible to disable for the cases were there is a legit use-case. as completed

By Pablo Correa Gomez on 2024-05-15T14:57:43

This has been fixed with !4994 (closed) and related MRs! Thanks everybody for working on this!

By Pablo Correa Gomez on 2024-05-15T14:58:20

closed

Consistent pkgver in device packages

Child items 0

Activity