Releases?

[morgant]

My apologies in advance if this is not the appropriate place to ask this. Do you plan to tag releases at any point?

I'd like to create and maintain an OpenBSD port of hfsfuse, but would realistically need tagged versions to do so.

Regardless, thanks for the excellent project!

[0x09]

@morgant that makes sense. hfsfuse follows the versioning strategy used by x264 and some other projects, where the HEAD of the master branch is treated as stable and the version is simply a revision number based on a linearization of the commit history, so I'll see if I can set something up to create actual releases in https://github.com/0x09/hfsfuse/releases based on that.

The good news is that OpenBSD is already part of a suite of OSes now being checked for build compatibility alluded to here so the porting effort should be smooth going forward.

[morgant]

@0x09 Ah, if that's the case, I should be able to base my port on OpenBSD's x264 port and just specify a date version and the commit. Releases would still be helpful, but not necessary, so only set that up if you think it'd be of additional use.

I greatly appreciate you already testing against OpenBSD.

[0x09]

I did initially check out if GHCOMMIT would be a more appropriate option here, but ended up not suggesting it only because the actual version string that goes into the binary is generated using information from the git repo at build time. This is missing from the auto-created zip that ports fetches when using the `GH*make vars. (The same actually applies for x264,x264 --versionfrom the OpenBSD package reportsx264 0.160.x` where x is a placeholder for the actual revision.)

This is basically the intent of including the make version target, in order to create distribution packages out of the git sources, so I think generating releases for this purpose makes sense.

[0x09]

@morgant would you be able to use something like this https://github.com/0x09/hfsfuse/releases/tag/0.113, where the actual distribution tarball is hfsfuse-0.113.tar.gz as opposed to the github generated source links? This seems in line with the guidance in https://www.openbsd.org/faq/ports/guide.html, specifically

In some cases, for example icinga or darktable, a distribution tar file has been prepared and is available in a /releases/ directory. Where available, use these in preference to other options as they usually include the proper build infrastructure (configure scripts, etc) which are often missing from "tagged" releases. Specify as normal, using something like MASTER_SITES=https://github.com/acct/project/releases/download/relname/

I added this release manually to test it out, but it should be reasonably simple to maintain automatically through actions (though hfsfuse does not really get/need a ton of activity in the first place.)

[morgant]

@0x09 I had built hfsfuse from the git repo and hadn't really looked at the specifics of the Makefile yet, so hadn't noticed the version info being built from the repo. Yeah, having distribution tarballs is certainly preferable, esp. in this case where it includes version info not contained in GitHub-generated archives (which are still preferable to checking out a specific revision).

Thanks for taking the time to put together a release manually this time and for your consideration of automating it. I have to admit I haven't switched to GitHub actions yet, otherwise I'd offer to help with that.

I'll put together a port, probably this weekend, and expect it'll be easy with the release tarball and having already successfully built it under 6.8/amd64-stable.

[morgant]

@0x09 I've got the initial OpenBSD port put together, pending a little more testing before submitting. You can preview it at https://github.com/morgant/my-openbsd-ports/tree/main/sysutils/hfsfuse.

The only two minor things I had to work around were:

• The version string isn't quoted in src/version.h
• PREFIX gets hardcoded in config.mak during gmake config, so OpenBSD's make fake process gets broken

Easy enough to patch, so just for your consideration when creating future releases.

Thanks again for putting the release together so it was easier for me to make the port!

[0x09]

@morgant if it makes it simpler, make config is really optional and more of a convenience to save configuration between make invocations. So make config <config flags> && make has the same effect as make <config flags> and MAKE_FLAGS/FAKE_FLAGS might be enough for this.

edit: also, I just pushed up some changes here that you may want to incorporate into the port already as these fix a bug where the local copy of utf8proc's headers were being included even when the library itself is linked externally with WITH_UTF8PROC=system.

[morgant]

@0x09 Ah, yeah, now why didn't I take that approach in the first place? Much simpler to just have no configure and set MAKE_FLAGS. Thanks for the new release, as well. I've incorporated both changes into my port, but still have to do some testing before submitting. I expect I'll do that this weekend.

[morgant]

I have submitted the OpenBSD port for review, so now we just wait and see.

@0x09 Regarding this issue, you're welcome to close it unless you want to keep it open until you've automated the release process.