On Tue, Aug 14, 2018 at 8:56 PM Helen Koike <[email protected]> wrote:
> > > On 08/13/2018 09:50 PM, blubee blubeeme wrote: > > > > > > On Tue, Aug 14, 2018, 08:26 Helen Koike <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > On 08/13/2018 08:00 PM, blubee blubeeme wrote: > > > > > > > > > On Tue, Aug 14, 2018, 06:30 Helen Koike <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > > > > Hello, > > > > > > I am new to the community, I am maintaining two packages and I > > would > > > like to check with you if there is a better workflow to do > this. > > > > > > The upstream project of the port I am maintaining is held in > > github, and > > > I also have patches in the /usr/ports/sysutils/myport/file/ > > folder. > > > > > > So I keep a fork of the upstream project with a branch > > containing a > > > commit with the patches from the > /usr/ports/sysutils/myport/file/. > > > > > > Every time I need to update the port to a newer version, I do > > a git pull > > > in this branch, then I run a script [1] to re-generate the > > patches in > > > the /usr/ports/sysutils/myport/file/ > This one is fairly straight forward, you can simply replace that string with a regex command; This is an example of running a replace command for strings after the patch phase of the build; post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README > > > > > > This script basically generates a file.orig of all modified > > files in > > > git, then copy the modified file to WORK_DIR, then run make > > makepatch. > > > > > > > > > for file in ${CHANGES}; do > > > mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig > > > cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file} > > > done > > > make makepatch > Depending on how drastic the changes are, you can use the above command to simply replace strings; There's also binary alias, that allows to replace sed with gsed: https://www.freebsd.org/doc/en/books/porters-handbook/binary-alias.html Speaking of which, FreeBSD has access to all the GNU tools such as; gmake [gnu make] gsed [gnu sed] if it's only a few commands you can use binary alias. If the project needs GNU tools, then FreeBSD also provides a way to automatically run the required scripts check section 6.5.3 configure Scripts: https://www.freebsd.org/doc/en/books/porters-handbook/building.html > > > > > > > > > I would like to know if there is a better way to do this (some > > tool that > > > I am not aware of?). > > > > > > [1] > > > > > > https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh > > > > > > Thanks > > > Helen > > > > > > _______________________________________________ > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> mailing > > > list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > To unsubscribe, send any mail to > > > "[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>" > > > > > > Submit your patches upstream, once they get accepted your work on > > > FreeBSD is greatly simplified. > > > > > > Best, > > > Owen > > > > > > > I am doing that, but there are some changes that I couldn't include > in > > upstream yet. > > > > Helen > > > > Can you give an example of types of changes can't be upstream yet and > > their reasoning why not? > > > > Best, > > Owen > > > > Sure, e.g. "service -e" vs "service --status-all", there is also sed vs > gsed (but it just came to mind that I could add this replacement inside > the Makefile) > > [1] > > https://github.com/freebsd/freebsd-ports/blob/master/sysutils/google-compute-engine-oslogin/files/patch-bin_google__oslogin__control#L54 > > Please, let me know if there is a better way to solve this, meanwhile I > am keeping this patch in the port and I always need to rebase my changes. > > And as a general case, I sometimes implement a fix only for FreeBSD e.g. > [2], then I think in the better way to include in the upstream code e.g. This is subjective; If you can use native FreeBSD facilities and get that upstreamed great, if it works and you don't have to maintain a bunch of patches, is it reasonable to use your time maintain diffs on something that's not broken? [3] while keeping portability with Linux, and sometimes it takes a while > for the patch to be merged in upstream, so meanwhile I need to rebase > the patch in every update of the ports. > This is just a waiting game, sure it might take a while to get the changes committed upstream but the temporary maintenance is a lot simpler than trying to keep that going forever, you'll most likely get burnt out. > > [2] > > https://github.com/freebsd/freebsd-ports/blob/master/sysutils/py-google-compute-engine/files/patch-google__compute__engine_networking_ip__forwarding_ip__forwarding__utils.py > > [3] https://github.com/GoogleCloudPlatform/compute-image-packages/pull/622 > > Thanks > Helen > A lot of the above is explained in the porters handbook under the slow porting section: https://www.freebsd.org/doc/en/books/porters-handbook/slow-porting.html Best, Owen _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
