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 <[email protected]> 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
