[aur-general] Fwd: Re: How do I show a AUR Rebuild as a newer build?
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 On 20/10/18 9:42 am, Ralf Mardorf wrote:
On Sat, 20 Oct 2018 08:59:06 +0800, hagar wrote:
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."
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.
On Sat, 20 Oct 2018 10:05:44 +0800, hagar wrote:
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
On Sat, Oct 20, 2018 at 10:05:44AM +0800, hagar wrote:
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 -- https://www.qutebrowser.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
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 On 20/10/18 4:24 pm, Florian Bruhin wrote:
On Sat, Oct 20, 2018 at 10:05:44AM +0800, hagar wrote:
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
On 20/10/2018 03:05, hagar wrote:
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.
On Sat, Oct 20, 2018 at 12:11:04 +0100, Jonathon Fernyhough wrote:
On 20/10/2018 03:05, hagar wrote:
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
On 10/20/18 7:51 AM, Tinu Weber wrote:
On Sat, Oct 20, 2018 at 12:11:04 +0100, Jonathon Fernyhough wrote:
On 20/10/2018 03:05, hagar wrote:
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." -- Eli Schwartz Bug Wrangler and Trusted User
On Sat, Oct 20, 2018 at 21:01:56 -0400, Eli Schwartz via aur-general wrote:
On 10/20/18 7:51 AM, Tinu Weber wrote:
On Sat, Oct 20, 2018 at 12:11:04 +0100, Jonathon Fernyhough wrote:
On 20/10/2018 03:05, hagar wrote:
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."
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
On 22/10/18 5:47 pm, Tinu Weber wrote:
On Sat, Oct 20, 2018 at 21:01:56 -0400, Eli Schwartz via aur-general wrote:
On 10/20/18 7:51 AM, Tinu Weber wrote:
On Sat, Oct 20, 2018 at 12:11:04 +0100, Jonathon Fernyhough wrote:
On 20/10/2018 03:05, hagar wrote:
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." 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
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.
On 22/10/2018 12.16, hagar wrote:
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
On 10/22/18 7:52 AM, LoneVVolf wrote:
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 .
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. -- Eli Schwartz Bug Wrangler and Trusted User
On 10/22/18 7:52 AM, LoneVVolf wrote:
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 .
1) This relays untrue information to the person reading the pkgver. disagree
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
On 22/10/2018 16.29, Eli Schwartz via aur-general wrote: pkgver
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.
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
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, October 22, 2018 11:47 AM, Tinu Weber <takeya@bluewin.ch> wrote:
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:
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
On 10/22/18 7:19 AM, mar77i via aur-general wrote:
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. -- Eli Schwartz Bug Wrangler and Trusted User
On 22/10/18 7:30 pm, Eli Schwartz via aur-general wrote:
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
On 10/22/18 7:19 AM, mar77i via aur-general wrote: 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
On 10/22/18 5:47 AM, Tinu Weber wrote:
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).
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.
* 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.
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". -- Eli Schwartz Bug Wrangler and Trusted User
On Mon, Oct 22, 2018 at 07:27:21 -0400, Eli Schwartz via aur-general wrote:
On 10/22/18 5:47 AM, Tinu Weber wrote:
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).
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.
[…] 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?
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
On Mon, Oct 22, 2018 at 16:16:27 +0200, Tinu Weber wrote:
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
On 10/22/18 10:16 AM, Tinu Weber wrote:
[…] 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".
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. :) -- Eli Schwartz Bug Wrangler and Trusted User
On 22/10/2018 11:27, Eli Schwartz via aur-general wrote:
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. ... 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 )
On 10/22/18 4:52 PM, Jonathon Fernyhough wrote:
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
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.
Anyway - this is OT and my own (self-inflicted?) problem.
Seems on topic to me. -- Eli Schwartz Bug Wrangler and Trusted User
On 22/10/2018 21:17, Eli Schwartz via aur-general wrote:
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
On 23/10/18 4:52 am, Jonathon Fernyhough wrote:
On 22/10/2018 11:27, Eli Schwartz via aur-general wrote:
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. ... 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
participants (8)
-
Eli Schwartz
-
Florian Bruhin
-
hagar
-
Jonathon Fernyhough
-
LoneVVolf
-
mar77i＠protonmail.ch
-
Ralf Mardorf
-
Tinu Weber