Attempt with `patch.pre_args -p0` On Wed, Oct 4, 2023 at 10:38 PM contextnerror <contextner...@outlook.com> wrote:
> 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 <j...@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 > >
