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.

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.

So it seems that in the Linux world, HFS+ support is stuck at 332 for the foreseeable future

If this is the case, should @Muflone remove the out-of-date flag? This package provides the latest Linux version of hfsprogs.

@LukeLR well, at the very least, you would have to take a look at those patches for v332, understand what they're supposed to be doing, decide which parts are still relevant, and adjust them so that they're compatible with v593. Then you would have to install the needed Linux libraries on your Mac, maybe modify Xcode in some way so it can see and utilize them, compile the binary, then distribute it. And you would have to do all this every time one of these libraries receives an update.

As things stand, I think it's safe to say that Apple is deliberately blocking the open source community from using its drivers by making it almost impossible to build them, so unless something changes, we should just accept the facts and make do with what we have until that too stops working. And as I said in my previous comment, "a bit sad in theory (because Linux is usually the king of compatibility between OSes) but mostly irrelevant in practice" because really, who cares about this piece of crap that is HFS+. It would be good to have compatibility, sure, but it's not the end of the world.