workflow question: how do you maintain the port in sync with upstream?

Tue Aug 14 14:41:56 UTC 2018

On Tue, Aug 14, 2018 at 8:56 PM Helen Koike <helen.koike at collabora.com>
wrote:

>
>
> On 08/13/2018 09:50 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018, 08:26 Helen Koike <helen.koike at collabora.com
> > <mailto:helen.koike at collabora.com>> wrote:
> >
> >
> >
> >     On 08/13/2018 08:00 PM, blubee blubeeme wrote:
> >     >
> >     >
> >     > On Tue, Aug 14, 2018, 06:30 Helen Koike <helen.koike at collabora.com
> >     <mailto:helen.koike at collabora.com>
> >     > <mailto:helen.koike at collabora.com
> >     <mailto:helen.koike at collabora.com>>> 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
> >     >
> >     >     _______________________________________________
> >     >     freebsd-ports at freebsd.org <mailto:freebsd-ports at freebsd.org>
> >     <mailto:freebsd-ports at freebsd.org
> >     <mailto:freebsd-ports at freebsd.org>> mailing
> >     >     list
> >     >     https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >     >     To unsubscribe, send any mail to
> >     >     "freebsd-ports-unsubscribe at freebsd.org
> >     <mailto:freebsd-ports-unsubscribe at freebsd.org>
> >     >     <mailto:freebsd-ports-unsubscribe at freebsd.org
> >     <mailto:freebsd-ports-unsubscribe at freebsd.org>>"
> >     >
> >     > 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