Updating alpine

[contextnerror ​]

Thanks for that advice.
I tried to use the patch from https://repo.or.cz/alpine.git/patch/701aebc00aff0585ce6c96653714e4ba94834c9c
This was with patch.pre_args -p1 applied as well.
It’s failing at pith/pine.hlp: "Hunk #1 FAILED at 147.”
Do I even need this file? I’m not sure how it’s related.


> On Oct 4, 2023, at 6:49 AM, Joshua Root <jmr at macports.org> wrote:
> 
> On 4/10/2023 15:05, contextnerror wrote:
>> I was hoping to update the portfile for alpine.
>> Currently the 2.26 release will not build due to a passfile bug, but this was fixed in a newer commit. (https://repo.or.cz/alpine.git)
>> I had a few questions about how to implement this:
>> - Should I add the changes as patchfiles, or just change the master site to the git repo?
>> - Would the version still be 2.26 or something else?
>> - Should I also add any of the other new fixes from git?
> 
> Fetching from a VCS should be avoided if possible, since we can't mirror the source in that case, and fetching is more likely to fail on restrictive networks. So probably patchfiles.
> 
> Usually we would not change the version when adding bug fix patches. If the version in the published ports tree were already 2.26 and you added a patch that changes the installed files in any way, you would of course increase the port's revision.
> 
> Normally you don't want to pull in all the changes that exist in an upstream repo, simply because if they were considered ready to use there would be a new release containing them. Some projects have very slow release cycles though, so if that's the case here, try to get some sense of the risk vs benefit for each change before deciding to incorporate it.
> 
> - Josh