Package Details: hfsprogs 540.1.linux3-1

Git Clone URL: https://aur.archlinux.org/hfsprogs.git (read-only)
Package Base: hfsprogs
Description: User space utils for create and check Apple HFS/HFS+ filesystem
Upstream URL: http://www.opensource.apple.com/
Licenses: custom:APSL
Submitter: Muflone
Maintainer: Muflone
Last Packager: Muflone
Votes: 40
Popularity: 1.114466
First Submitted: 2017-10-01 14:46
Last Updated: 2018-12-26 17:16

Pinned Comments

Muflone commented on 2018-12-26 17:19

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.

Latest Comments

1 2 Next › Last »

Rhinoceros commented on 2019-01-01 00:02

Thanks @Muflone!

Muflone commented on 2018-12-26 17:19

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.

Nocifer commented on 2018-12-23 13:19

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

Rhinoceros commented on 2018-12-21 10:54

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.

Nocifer commented on 2018-12-21 10:27

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.

Rhinoceros commented on 2018-12-20 21:46

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.

Nocifer commented on 2018-12-06 22:11

@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.

LukeLR commented on 2018-11-30 00:23

I have a bit of knowledge, and access to a Mac. What would I need to do to compile recent hfsprogs with Xcode and distribute it for Linux?

Muflone commented on 2018-11-02 23:03

I was maintaining this package in the official community repository but I was unable to successfully build a newer version so finally I've decided to drop the package in AUR.

If someone can share some hint to update this package please do. Until then I'm unable to provide further updates.

Nocifer commented on 2018-11-02 12:10

So I took a peek at https://opensource.apple.com/tarballs/diskdev_cmds/ , and it seems Apple has stopped providing makefiles for its packages since version 572 (4 releases ago) and has changed the build procedure so that it must be done through Xcode, which pretty much means one needs a Mac to do it.

The latest version with accompanying makefiles is version 557, but it too can't be used because in order to be built properly on Linux this package needs to modify the sourcefiles with some Linux-specific patches, and the Debian package from which it derives those patches is also stuck at version 332.

So it seems that in the Linux world, HFS+ support is stuck at 332 for the foreseeable future (unless some kind soul builds the package on a Mac and then provides us with the compiled binaries).

A bit sad in theory (because Linux is usually the king of compatibility between OSes) but mostly irrelevant in practice. Oh well.