Arch Linux User Repository

Package updated to version 540.1 in a specific build compatible with GNU/Linux.

Please do not mark this package out of date since you personally are able to build the package against the newer sources.

Cannot be compiled anymore:

makehfs.c:41:10: fatal error: sys/sysctl.h: No such file or directory 41 | #include <sys/sysctl.h> | ^~~~~~~~~~~~~~ compilation terminated.

glibc 2.32 removed deprecated sysctl.h.

Could you add fsck.hfs > fsck.hfsplus and mkfs.hfs > mkfs.hfsplus symlinks?

please add architecture for RaspberryPi. 'armv6h' and 'armv7h'. Builds correctly on both.

Apple sources since many years are not compatible with GNU/Linux as they use a lot of libraries and headers unexistant for GNU/Linux.

The package version 540.1 uses a forked project, compatible with GNU/Linux. Just compare the two sources to know why patches cannot be applied to Apple sources.

Hello, I don’t fully understand what’s happening with this package. What I’ve understood is that:

• Apple does not provide Makefiles and only build diskdev with XCode;

• You’ve managed to write a Makefile that does the job.

• Does it only works with version 540?

• Have you modified something else?
• Couldn’t we download directly the archive from Apple’s servers and apply the Makefile as a patch, or directly in the PKGBUILD?

Thanks!

Thanks @Muflone!

Package updated to version 540.1 in a specific build compatible with GNU/Linux.

Please do not mark this package out of date since you personally are able to build the package against the newer sources.

Yes, if it was a case like e.g. Skype, with completely separate versions (and codebases) for each platform, then this package should obviously not be flagged as out of date. But, as already said, the sources are one and the same across all platforms, Linux included, so it's just a matter of building them; a task which Apple has made all but impossible for platforms other than macOS by deprecating the old (via CMake) build process and replacing it with a new one that is compatible with nothing else but Macs (via XCode), but officially the sources are still out there and are still being updated regularly, so in theory anyone can grab them and build the binary for themselves. And by that token it's perfectly conceivable that at any point in the future Some Random Guy (or even Apple itself if it changes its mind) could use the up-to-date sources to create and provide us with fresh, up-to-date instructions for CMake (or even Mason, or whichever other build system).

So, the AUR package being a number of versions behind isn't due to source unavailability or binary incompatibility or licensing issues or for some other insurmountable reason, it's merely a combination of Apple's lack of interest in and/or indirect sabotaging of (take your pick) open source, and an equivalent lack of interest from people on the Linux side who probably find no good reason to waste their time doing Apple's job in order to bypass its shenanigans and build the latest binary with an open source toolchain and then provide us with a proper patch set, and all that for something that isn't even used outside of Apple's small world and is also quite literally crap quality-wise (I'm talking about the HFS+ filesystem here) - it's simply not worth the effort. So it can be done, it just isn't being done. That's imho the very definition of "out of date" as regards to AUR packages.

Finally, there is also the matter of having a not up-to-date package showing as up-to-date on its AUR page, which can be very misleading.

All that said, I get your point of view and I don't completely disagree with the notion that this package is for all intents and purposes at the "latest" version as far as Linux is concerned. And really, it's hfsprogs we're talking about, so I can't say I'm going to lose any sleep over whatever happens to it. For the reasons outlined above I'm for "out of date", but... yeah.

One last thing: I too use yay, but objectively speaking an AUR wrapper's functions are simply its creator's choices, and they should not be used as a basis for AUR policy. As an extremely over the top example, tomorrow yay could introduce a "feature" that notifies you whenever there is an AUR update by making your PC's speaker go permanently beeeeeeeeeeeeep until you update - should that be a reason for making AUR's updates to auto-install?

P.S. - The above are for conversational purposes only, they're not intended as a polemic. If I haven't already stressed it enough: it's hfsprogs we're talking about :P

Okay, I haven't delved into the background deeply myself. I was interpreting it as the latest version being released as incompatible with Linux, since we would need a Mac to compile it. I imagined that it was analogous to having the newest version of Skype on Windows, but Linux lagging behind. The other thing is that AUR helpers such as yay keep putting up warnings that this package is out-of-date. To me, that generally means that the maintainer is being lax in bumping the version, and I should request an adoption. In a sense, I wouldn't want to know if someone needed to build it on a Mac; also, this would have to be released as hfsprogs-bin… making hfsprogs not out-of-date? However, that's just my interpretation, which is not based on anything official, so I'm happy to be wrong here.

Well, in theory the source is open and cross-platform and it's simply a matter of no one having "bothered" to build the latest version for Linux, so technically speaking this package is out of date, and it should probably stay as it is to reflect that fact. Not to mention that showing as out of date might, at some point in the future, act as motive for someone to rebase the patches and build us a binary, if it's at all possible.