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

[hagar]

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.