[aur-general] How do I show a AUR Rebuild as a newer build?

[hagar]

Good morning All,

I understand that there are 3 version control tags in the PKGBUILD file.


pkgver - The Actual Package version

pkgrel - The Arch modification/release count - for changes to the
patches, install file's.

epoch - Special version control number.


If I need to rebuild a package due to dependancy rebuilds/changes how do
I mark the new package as newer?


Do I increase the epoch?

Or is there another way?


Thanks

Macca

[Ralf Mardorf]

Post by hagar
If I need to rebuild a package due to dependancy rebuilds/changes how
do I mark the new package as newer?
Do I increase the epoch?

No.

From 'man PKGBUILD':

"This is useful when the version numbering scheme of a package changes
(or is alphanumeric), breaking normal version comparison logic."

Post by hagar
Or is there another way?

That is what the pkgrel is for.

However, AUR provides PKGBUILDs, not packages, so a maintainer doesn't
bump the pkgrel each time a PKGBUILD gets edited, but a maintainer
might care about the need to build against newer releases of
dependencies and increase the pkgrel or the maintainer might ignore it.
What ever changed, I bump the pkgrel for my local builds for each
package, but that way the pkgrels of my local packages could get out of
sync with the pkgrels of some AUR PKGBUILDs. If you dislike this,
simply build a new package with the same pkgver-pkgrel or the same
epoch:pkgver-pkgrel, if there already should be an epoch.

[hagar]

This was my thought - then I came across Mythtv -

epoch=1

pkgrel=5

pkgver=29.1


The docs say that pkgrel should be for changes in the packaging files.

Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.

This would allow for 99 subsequent builds on each pkgrel.

The docs say that it can be of type ver.subver.

would this work?


Thanks

Macca

Post by Ralf Mardorf

Post by hagar
If I need to rebuild a package due to dependancy rebuilds/changes how
do I mark the new package as newer?
Do I increase the epoch?

No.
"This is useful when the version numbering scheme of a package changes
(or is alphanumeric), breaking normal version comparison logic."

Post by hagar
Or is there another way?

That is what the pkgrel is for.
However, AUR provides PKGBUILDs, not packages, so a maintainer doesn't
bump the pkgrel each time a PKGBUILD gets edited, but a maintainer
might care about the need to build against newer releases of
dependencies and increase the pkgrel or the maintainer might ignore it.
What ever changed, I bump the pkgrel for my local builds for each
package, but that way the pkgrels of my local packages could get out of
sync with the pkgrels of some AUR PKGBUILDs. If you dislike this,
simply build a new package with the same pkgver-pkgrel or the same
epoch:pkgver-pkgrel, if there already should be an epoch.

[Ralf Mardorf]

I was considering increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I don't know if anything is speaking against doing this. I suspect
there's nothing wrong with doing it this way, but I might be mistaken.

It at least is possible to do it:

$ pacman -Qi pulseaudio-bluetooth | head -3
Name : pulseaudio-bluetooth
Version : 2017.12.19-1
Description : Dummy package
$ sudo pacman -U pulseaudio-bluetooth-2017.12.19-1.01-any.pkg.tar.xz
[snip]

Packages (1) pulseaudio-bluetooth-2017.12.19-1.01

Total Installed Size: 0.00 MiB
Net Upgrade Size: 0.00 MiB

:: Proceed with installation? [Y/n] n

[Florian Bruhin]

Because of the Maintainers increasing pkgrel I was considering increasing
the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.

You can probably just start with .1, as .10 is bigger than .1 (or .2)
according to 'vercmp' which pacman uses for version comparisons.

The docs say that it can be of type ver.subver.
would this work?

I do that for my modified Qt packages sometimes, when I add additional
patches on top of Arch's ones:
https://github.com/qutebrowser/qt-debug-pkgbuild

Never ran into any issues.

Florian

[hagar]

Thanks all for the information.

It would probably help if this information was more easily available and
explained when reading the docs.

Especially the below information.

Thanks
Macca

Post by Florian Bruhin

Because of the Maintainers increasing pkgrel I was considering increasing
the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.

You can probably just start with .1, as .10 is bigger than .1 (or .2)
according to 'vercmp' which pacman uses for version comparisons.

The docs say that it can be of type ver.subver.
would this work?

I do that for my modified Qt packages sometimes, when I add additional
https://github.com/qutebrowser/qt-debug-pkgbuild
Never ran into any issues.
Florian

[Jonathon Fernyhough]

Post by hagar
Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I use this approach when rebuilding any archlinux32 packages for
manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1
-> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump
(1.0 -> 1.01 etc.).

This has worked well so far, and ensures the correct cascade of updates
as changes happen upstream.

[Tinu Weber]

Post by Jonathon Fernyhough

Post by hagar
Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I use this approach when rebuilding any archlinux32 packages for
manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1
-> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump
(1.0 -> 1.01 etc.).

Wouldn't that be a "hundredth"? :-P

Joke aside, vercmp seems to cope fine even for multiple dots (so you
could have something like 1.0.1 in the pkgrel).

Best,
Tinu

[Eli Schwartz via aur-general]

Post by Tinu Weber

Post by Jonathon Fernyhough

Post by hagar
Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I use this approach when rebuilding any archlinux32 packages for
manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1
-> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump
(1.0 -> 1.01 etc.).

Wouldn't that be a "hundredth"? :-P
Joke aside, vercmp seems to cope fine even for multiple dots (so you
could have something like 1.0.1 in the pkgrel).

No you cannot, makepkg is far stricter than pacman/libalpm/vercmp about
most things, and in this case, as with many other packaging details,
makepkg explicitly forbids this.

Allan has stated his absolute refusal to permit it:
https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022578.html

"I am still very much against going beyond x.y for pkgrel. In fact, I
only begrudgingly accept the need for .y in there."

[Tinu Weber]

Post by Eli Schwartz via aur-general

Post by Tinu Weber

Post by Jonathon Fernyhough

Post by hagar
Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I use this approach when rebuilding any archlinux32 packages for
manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1
-> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump
(1.0 -> 1.01 etc.).

Wouldn't that be a "hundredth"? :-P
Joke aside, vercmp seems to cope fine even for multiple dots (so you
could have something like 1.0.1 in the pkgrel).

No you cannot, makepkg is far stricter than pacman/libalpm/vercmp about
most things, and in this case, as with many other packaging details,
makepkg explicitly forbids this.
https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022578.html
"I am still very much against going beyond x.y for pkgrel. In fact, I
only begrudgingly accept the need for .y in there."

Ah, indeed. I'm sorry, I should've tested with makepkg.

More generally, however, what would be the best approach to applying
downstream/user-specific changes without breaking the versioning? The
ones I know all have some issue:

* Dotted pkgrel (as I suggested) breaks if the package maintainer
decides to assign a dotted pkgrel themself (say the pkgrel is 1, and
we change it to 1.1, 1.2, ..., but then suddenly the maintainer
assigns 1.1 themself).
* pkgrel "suffixes" don't work because 1foo1 < 1 (also, makepkg refuses
this anyway).
* The approach shown by Jonathon above also breaks (unless I've
misunderstood it): 1.0 -> 1.01, but vercmp tells me that 1.01 = 1.1.

Or is the answer simply: "Don't rely on package versioning for your
modified packages"?

Best,
Tinu

[hagar]

Post by Tinu Weber

Post by Eli Schwartz via aur-general

Post by Tinu Weber

Post by Jonathon Fernyhough

Post by hagar
Because of the Maintainers increasing pkgrel I was considering
increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?

I use this approach when rebuilding any archlinux32 packages for
manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1
-> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump
(1.0 -> 1.01 etc.).

Wouldn't that be a "hundredth"? :-P
Joke aside, vercmp seems to cope fine even for multiple dots (so you
could have something like 1.0.1 in the pkgrel).

No you cannot, makepkg is far stricter than pacman/libalpm/vercmp about
most things, and in this case, as with many other packaging details,
makepkg explicitly forbids this.
https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022578.html
"I am still very much against going beyond x.y for pkgrel. In fact, I
only begrudgingly accept the need for .y in there."

Ah, indeed. I'm sorry, I should've tested with makepkg.
More generally, however, what would be the best approach to applying
downstream/user-specific changes without breaking the versioning? The
* Dotted pkgrel (as I suggested) breaks if the package maintainer
decides to assign a dotted pkgrel themself (say the pkgrel is 1, and
we change it to 1.1, 1.2, ..., but then suddenly the maintainer
assigns 1.1 themself).
* pkgrel "suffixes" don't work because 1foo1 < 1 (also, makepkg refuses
this anyway).
* The approach shown by Jonathon above also breaks (unless I've
misunderstood it): 1.0 -> 1.01, but vercmp tells me that 1.01 = 1.1.
Or is the answer simply: "Don't rely on package versioning for your
modified packages"?
Best,
Tinu

Unfortunately maybe something is needed as I use a local repository to
serve my localnet.

I build once and then install by update from my repository.

Several times I have had to rebuild a package due to a dependency
version change.

In order for the other computers to recognize and download a rebuild the
version has to increase somehow.

Maybe an actual policy is required to control these rebuilds.


For example Anjuta.

This package does require a rebuild as a dependency has changed leading
to a broken executable.

I have had to rebuild it on my own server in order to fix it as it has
not been rebuilt yet.

[LoneVVolf]

Post by hagar

Post by Tinu Weber
Or is the answer simply: "Don't rely on package versioning for your
modified packages"?
Best,
Tinu

Unfortunately maybe something is needed as I use a local repository to
serve my localnet.
I build once and then install by update from my repository.
Several times I have had to rebuild a package due to a dependency
version change.
In order for the other computers to recognize and download a rebuild the
version has to increase somehow.
Maybe an actual policy is required to control these rebuilds.
For example Anjuta.
This package does require a rebuild as a dependency has changed leading
to a broken executable.
I have had to rebuild it on my own server in order to fix it as it has
not been rebuilt yet.

I think this can be solved by clarifying what upstream is.


example :
archlinux foo package has foo.org as upstream
archlinux32 uses archlinux foo package as base , upstream = archlinux
manjaro32 uses archlinux32 package as base , upstream = archlinux32

say foo is at version 8.2.5
archlinux has 8.2.5-2
archlinux32 then uses 8.2.5.arch.2 as pkgver and adds 3 as their pkgrel
manjaro32 uses 8.2.5.2.arch.2.arch32.3 as pkgver and their own pkgrel.

This shows the chain between downstream and all upstreams .

LVV

[Eli Schwartz via aur-general]

Post by LoneVVolf
I think this can be solved by clarifying what upstream is.
archlinux foo package has foo.org as upstream
archlinux32 uses archlinux foo package as base , upstream = archlinux
manjaro32 uses archlinux32 package as base , upstream = archlinux32
say foo is at version 8.2.5
archlinux has 8.2.5-2
archlinux32 then uses 8.2.5.arch.2 as pkgver and adds 3 as their pkgrel
manjaro32 uses 8.2.5.2.arch.2.arch32.3 as pkgver and their own pkgrel.
This shows the chain between downstream and all upstreams .

1) This relays untrue information to the person reading the pkgver.

2) This requires rewriting the whole PKGBUILD to use secondary proxy
variables everywhere that $pkgver is currently being used, like most
paths and the source array.

3) It made me throw up when I read that.

4) https://www.parabola.nu/ has forked the pacman package to add pkgrel
distro-specific support for 2.1.parabola1 style pkg *rel*, because
they consider this sort of sharp deviation from upstream makepkg to
be superior to messing with the pkgver.

[LoneVVolf]

Post by Eli Schwartz via aur-general

Post by LoneVVolf
I think this can be solved by clarifying what upstream is.
archlinux foo package has foo.org as upstream
archlinux32 uses archlinux foo package as base , upstream = archlinux
manjaro32 uses archlinux32 package as base , upstream = archlinux32
say foo is at version 8.2.5
archlinux has 8.2.5-2
archlinux32 then uses 8.2.5.arch.2 as pkgver and adds 3 as their pkgrel
manjaro32 uses 8.2.5.2.arch.2.arch32.3 as pkgver and their own pkgrel.
This shows the chain between downstream and all upstreams .

1) This relays untrue information to the person reading the pkgver.

disagree

Post by Eli Schwartz via aur-general
2) This requires rewriting the whole PKGBUILD to use secondary proxy
variables everywhere that $pkgver is currently being used, like most
paths and the source array.

simply solved : introduce one new var, _realver and use that instead of
pkgver

Post by Eli Schwartz via aur-general
3) It made me throw up when I read that.

If you have stomach problems go see a doctor.
If this is supposed to be some kind of metaphor, it failed to convey
it's meaning.

Post by Eli Schwartz via aur-general
4) https://www.parabola.nu/ has forked the pacman package to add pkgrel
distro-specific support for 2.1.parabola1 style pkg *rel*, because
they consider this sort of sharp deviation from upstream makepkg to
be superior to messing with the pkgver.

The ability to fork is one of the strong points of Open Source Software.


--------------------

Mr Schwartz, your replies to my posts in this and earlier threads
indicate you very often misunderstand me.
I have often not responded to replies from you on posts by me because it
is/was very hard to not become hostile towards you in those replies.

To all :
In the 2 posts (including this one) I've made in this thread I have only
made suggestions. I have not once stated whether they are smart / dumb,
good/bad or have any other value .
I expect readers to be able to use their own judgment for that.

In order to improve the chances this thread will be useful, I will not
post in it anymore.

Lone_Wolf

[mar77i via aur-general]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Post by Tinu Weber
More generally, however, what would be the best approach to applying
downstream/user-specific changes without breaking the versioning? The

I must be misreading this, because I don't see why you shouldn't use the exact same pkgver/pkgrel as the original package? If you want to port the modified package to the subsequent pkgrel or pkgver, you can always put the package on hold or figure out another way to be aware of . I think what we should be thinking about is to actually make it easier to serve this need in pacman itself somehow, if there isn't already a practicable way. There seems to be a way to list packages to upgrade before -Syu, IIRC.

If you added an obvious modification to your package or something similar, the dumb (admittedly maybe, not always easily debugged) way to notice that you overwrote a local modification is when it's gone...

cheers!
mar77i

[Eli Schwartz via aur-general]

Post by mar77i via aur-general
I must be misreading this, because I don't see why you shouldn't use
the exact same pkgver/pkgrel as the original package? If you want to
port the modified package to the subsequent pkgrel or pkgver, you can
always put the package on hold or figure out another way to be aware
of . I think what we should be thinking about is to actually make it
easier to serve this need in pacman itself somehow, if there isn't
already a practicable way. There seems to be a way to list packages
to upgrade before -Syu, IIRC.
If you added an obvious modification to your package or something
similar, the dumb (admittedly maybe, not always easily debugged) way
to notice that you overwrote a local modification is when it's
gone...

The point here is when you're not making modifications, but simply
rebuilding it, because libfoo.so had a soname bump. Without bumping the
pkgrel, pacman does not see this as an upgrade, and this has
ramifications for e.g. aurutils workflows.

If you do bump the pkgrel, you run the risk of not being able to compare
the version to the version returned by the AUR RPC interface, and not
noticing when it's time to pull a new, remote modification.

[hagar]

Post by Eli Schwartz via aur-general

Post by mar77i via aur-general
I must be misreading this, because I don't see why you shouldn't use
the exact same pkgver/pkgrel as the original package? If you want to
port the modified package to the subsequent pkgrel or pkgver, you can
always put the package on hold or figure out another way to be aware
of . I think what we should be thinking about is to actually make it
easier to serve this need in pacman itself somehow, if there isn't
already a practicable way. There seems to be a way to list packages
to upgrade before -Syu, IIRC.
If you added an obvious modification to your package or something
similar, the dumb (admittedly maybe, not always easily debugged) way
to notice that you overwrote a local modification is when it's
gone...

The point here is when you're not making modifications, but simply
rebuilding it, because libfoo.so had a soname bump. Without bumping the
pkgrel, pacman does not see this as an upgrade, and this has
ramifications for e.g. aurutils workflows.
If you do bump the pkgrel, you run the risk of not being able to compare
the version to the version returned by the AUR RPC interface, and not
noticing when it's time to pull a new, remote modification.

This is exactly my problem.

Especially since I was preparing to share my build repository online.

I have 202 packages (so far) from Android SDK's to kodi and mythtv


Thanks

Macca

[Eli Schwartz via aur-general]

Post by Tinu Weber
Ah, indeed. I'm sorry, I should've tested with makepkg.
More generally, however, what would be the best approach to applying
downstream/user-specific changes without breaking the versioning? The
* Dotted pkgrel (as I suggested) breaks if the package maintainer
decides to assign a dotted pkgrel themself (say the pkgrel is 1, and
we change it to 1.1, 1.2, ..., but then suddenly the maintainer
assigns 1.1 themself).

I've never really seen a dotted pkgrel in the wild, except for cases
like archlinux32 which use them to indicate their own rebuilds. I've
happily used them since forever, for AUR packages where I rebuild them
without an AUR pkgrel bump. It seems quite reasonable to me.

Post by Tinu Weber
* pkgrel "suffixes" don't work because 1foo1 < 1 (also, makepkg refuses
this anyway).
* The approach shown by Jonathon above also breaks (unless I've
misunderstood it): 1.0 -> 1.01, but vercmp tells me that 1.01 = 1.1.

To clarify the confusion here, this is not a decimal.

1.0 is no different here than in the pkgver itself -- it is 1, and a
subrel of 0.

1.01 is 1, with a subrel of 01, which is just 1, and therefore identical
to 1.1

1.11 would be a subrel that is two steps more significant than a subrel
of 9.

So Jonathon's system only works at all, due to the fact that whenever
archlinux32 downgrades the pkgrel, he upgrades it again. Which isn't
really working. More generally, the pkgrel system allowed by the makepkg
spec doesn't acknowledge the use case of infinitely cascading derivatives.

Post by Tinu Weber
Or is the answer simply: "Don't rely on package versioning for your
modified packages"?

I'm not the best person to answer this question, since my instinctive
reaction would be "okay, let's move this to [community] to make my life
easier".

[Tinu Weber]

Post by Eli Schwartz via aur-general

Post by Tinu Weber
Ah, indeed. I'm sorry, I should've tested with makepkg.
More generally, however, what would be the best approach to applying
downstream/user-specific changes without breaking the versioning? The
* Dotted pkgrel (as I suggested) breaks if the package maintainer
decides to assign a dotted pkgrel themself (say the pkgrel is 1, and
we change it to 1.1, 1.2, ..., but then suddenly the maintainer
assigns 1.1 themself).

I've never really seen a dotted pkgrel in the wild, except for cases
like archlinux32 which use them to indicate their own rebuilds. I've
happily used them since forever, for AUR packages where I rebuild them
without an AUR pkgrel bump. It seems quite reasonable to me.

There was lib32-fontconfig at one point [1], so adding a .1 or .2 to
that pkgrel wouldn't have worked with makepkg.

Post by Eli Schwartz via aur-general
[
] More generally, the pkgrel system allowed by the makepkg
spec doesn't acknowledge the use case of infinitely cascading derivatives.

That makes me sad, but I'll accept that as an anwer.

How about pacman/libalpm/vercmp? Can I rely on them treating multiply
dotted pkgrels as expected, or have I entered "expect your stuff to
break one day" territory?

Post by Eli Schwartz via aur-general

Post by Tinu Weber
Or is the answer simply: "Don't rely on package versioning for your
modified packages"?

I'm not the best person to answer this question, since my instinctive
reaction would be "okay, let's move this to [community] to make my life
easier".

Heh.

I guess for the mortals among us, the best/cleanest way is to bump the
pkgVER (as pointed out by LoneVVolf [2]), and stop attributing any sort
of semantic meaning (upstream/downstream) to the pkgrel?

Best,
Tinu


[1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/lib32-fontconfig&id=b225dccc1f415ceb05c3ec85ff100eb556603613
[2] https://lists.archlinux.org/pipermail/aur-general/2018-October/034385.html

[Tinu Weber]

Post by Tinu Weber
I guess for the mortals among us, the best/cleanest way is to bump the
pkgVER (as pointed out by LoneVVolf [2]), and stop attributing any sort
of semantic meaning (upstream/downstream) to the pkgrel?


 or, well, judging from your response in that thread, probably not ^^"

So I will stick to my poor person's approach of appending dots to
pkgrels, and nobody¹ will stop me, muahahah!

(but I *do* retract the suggestion I made earlier to other people to do
the same - apologies)

Have a nice day!
--Tinu


___
¹ except pacman/libalpm/vercmp

[Eli Schwartz via aur-general]

Post by Tinu Weber

Post by Eli Schwartz via aur-general
[
] More generally, the pkgrel system allowed by the makepkg
spec doesn't acknowledge the use case of infinitely cascading derivatives.

That makes me sad, but I'll accept that as an anwer.
How about pacman/libalpm/vercmp? Can I rely on them treating multiply
dotted pkgrels as expected, or have I entered "expect your stuff to
break one day" territory?

We officially don't allow it, but our spec for what is allowed is "does
makepkg lint it as an error".

pacman/libalpm is extremely liberal about what it accepts, the current
limits are, more or less, "it cannot have newlines, NULL bytes, or a /".
pkgver also cannot have "-". Andrew Gregory documents these practical
limits here: https://wiki.archlinux.org/index.php/User:Apg#pacman_LIMITS

The first two are because of the .PKGINFO line-based format.

The last is only because if you do, the pacman "local" database, which
is just a directory "${pkgname}-${full_epoch_pkgver_pkgrel}" containing
a file called "desc".

Post by Tinu Weber
I guess for the mortals among us, the best/cleanest way is to bump the
pkgVER (as pointed out by LoneVVolf [2]), and stop attributing any sort
of semantic meaning (upstream/downstream) to the pkgrel?

Um, yeah, just noticed your email. :)

[Jonathon Fernyhough]

Post by Eli Schwartz via aur-general
To clarify the confusion here, this is not a decimal.
1.0 is no different here than in the pkgver itself -- it is 1, and a
subrel of 0.

...

Post by Eli Schwartz via aur-general
So Jonathon's system only works at all, due to the fact that whenever
archlinux32 downgrades the pkgrel, he upgrades it again.

This is good information.

I've not seen this cause an issue yet, but probably only because arch32
don't tend to increment subrel.

I'll need to find another approach here... I can see this causing
spurious errors with packages built against different/incorrect library
versions (i.e. I rebuild 1.0 as 1.01 then arch32 rebuild as 1.1 and it's
not seen as a newer version).

I _really_ don't want to start hacking makepkg to remove/bypass the
"ERROR: pkgrel must be a decimal".

Anyway - this is OT and my own (self-inflicted?) problem.

J

( and yes, hundredths - but then _"technically"_ all hundredths are also
thousandths :P )

[Eli Schwartz via aur-general]

Post by Jonathon Fernyhough
I'll need to find another approach here... I can see this causing
spurious errors with packages built against different/incorrect library
versions (i.e. I rebuild 1.0 as 1.01 then arch32 rebuild as 1.1 and it's
not seen as a newer version).

I suppose you could collaborate so that they use 1.10 and you use 1.11

10 < 11 < 20

Post by Jonathon Fernyhough
I _really_ don't want to start hacking makepkg to remove/bypass the
"ERROR: pkgrel must be a decimal".

Which parabola does, but they also have people who hack on makepkg, and
if pacman started rejecting these packages they would be sufficiently
motivated to maintain compatibility in in their own distribution. They
make heavy use of this, so I guess it makes sense for internal use.

Post by Jonathon Fernyhough
Anyway - this is OT and my own (self-inflicted?) problem.

Seems on topic to me.

[Jonathon Fernyhough]

Post by Eli Schwartz via aur-general
I suppose you could collaborate so that they use 1.10 and you use 1.11
10 < 11 < 20

I like this for three reasons:

10 Collaboration
20 Fixes my problem
30 Reminds me of BASIC line numbering to allow space for "missed" lines
15 GOTO 10

[hagar]

Post by Jonathon Fernyhough

Post by Eli Schwartz via aur-general
To clarify the confusion here, this is not a decimal.
1.0 is no different here than in the pkgver itself -- it is 1, and a
subrel of 0.

...

Post by Eli Schwartz via aur-general
So Jonathon's system only works at all, due to the fact that whenever
archlinux32 downgrades the pkgrel, he upgrades it again.

This is good information.
I've not seen this cause an issue yet, but probably only because arch32
don't tend to increment subrel.
I'll need to find another approach here... I can see this causing
spurious errors with packages built against different/incorrect library
versions (i.e. I rebuild 1.0 as 1.01 then arch32 rebuild as 1.1 and it's
not seen as a newer version).
I _really_ don't want to start hacking makepkg to remove/bypass the
"ERROR: pkgrel must be a decimal".
Anyway - this is OT and my own (self-inflicted?) problem.
J
( and yes, hundredths - but then _"technically"_ all hundredths are also
thousandths :P )

Maybe thats the answer.

We add .rebld.[0-9]* to the end of pkgrel as a rebuild tag.

It just involves changing 1 line in -

/usr/share/makepkg/lint_pkgbuild/pkgrel.sh

change -

        if [[ $pkgrel != +([0-9])?(.+([0-9])) ]]; then
to -

        if [[ $pkgrel != +([0-9])?(.+([0-9])) -a $pkgrel !=
+([0-9])?(.+([0-9])).rebld.([0-9])* ]]; then

or it might be modified to add this automatically based on what is
currently installed.


Macca

[Filipe Laíns via aur-general]

Hey,

Post by hagar
Good morning All,
I understand that there are 3 version control tags in the PKGBUILD file.
pkgver - The Actual Package version

Yes. This is the main control version.

Post by hagar
pkgrel - The Arch modification/release count - for changes to the
patches, install file's.

This is an extra control version. 1.5.0-2 will be marked as a newer
version over 1.5.0-1 and will show up in the updates. That's what you
should be bumping if you need to rebuild the package. It will provide a
the same version but in a new iteration/build of the package.

Post by hagar
epoch - Special version control number.

This is only used if you need to do rollbacks.

Here's the version hierarchy:
epoch > pkgver > pkgrel

The version 2:1.4.0 will be higher in the hierarchy than 1:1.5.0, so
pacman will remove 1:1.5.0 and install 2:1.4.0 on system updates.

Post by hagar
If I need to rebuild a package due to dependancy rebuilds/changes how do
I mark the new package as newer?

Bump the pkgrel.

Post by hagar
Do I increase the epoch?

No. You never touch the epoch unless you need to rollback a package.

Post by hagar
Or is there another way?

No.

Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

[Eli Schwartz via aur-general]

Post by Filipe Laíns via aur-general

Post by hagar
epoch - Special version control number.

This is only used if you need to do rollbacks.

Rollbacks are but one of many reasons to use an epoch, take a look at
blender which has 17 of them and I don't think it's ever been rolled
back once.

Among other things, not much you can do when upstream releases version
"1a" as an *update* to version "1", when pacman considers "1a" to be a
beta/prerelease of "1".

[Eli Schwartz via aur-general]

Post by hagar
Good morning All,
I understand that there are 3 version control tags in the PKGBUILD file.
pkgver - The Actual Package version

https://wiki.archlinux.org/index.php/PKGBUILD#pkgver

Post by hagar
pkgrel - The Arch modification/release count - for changes to the
patches, install file's.

https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel

Post by hagar
epoch - Special version control number.

https://wiki.archlinux.org/index.php/PKGBUILD#epoch

Post by hagar
If I need to rebuild a package due to dependancy rebuilds/changes how do
I mark the new package as newer?
Do I increase the epoch?
Or is there another way?

One of these three descriptions explicitly describes itself as
"differentiate between consecutive builds of the same version of a package"

Rebuilding for a dependency update does, I suppose, qualify as a
consecutive rebuild of the same version of a package. :)

The fact that it then describes a non-exhaustive list of things which
result in consecutive rebuilds (those things being "fixes and additional
features"), should not be taken to mean those are the *only* things.