MacFUSE should have package-based installer about macfuse

[GoogleCodeExporter]

I'll make a pkg and an iceberg file to continue distributing this with. The 
only downside with iceberg is that it 
runs a root owned process, but it can be turned off once it's done.

Original comment by [email protected] on 11 Jan 2007 at 9:24

[GoogleCodeExporter]

Here's a preliminary one and the associated pmproj file I used.

Note the postflight script which loads the kext for you if the target volume 
matches
the boot volume.

Original comment by [email protected] on 11 Jan 2007 at 9:35

Attachments:

• MacFUSE-0.1.0b004-3.pkg.dmg
• MacFUSE-0.1.0b004-3.pmproj
• postflight

[GoogleCodeExporter]

Hrmm, using pmproj is probably better. I'll leave it to you mccune.jeff since 
you've already got that done.

Original comment by [email protected] on 11 Jan 2007 at 9:40

[GoogleCodeExporter]

I'm afraid we currently have no plans to release or maintain binary package (We 
reserve the right to change our 
mind, of course :-)) The binary package made available today was a one-time 
convenience thing done so that 
early (earliest) adopters could try things without much inertia.

Original comment by [email protected] on 12 Jan 2007 at 5:13

• Changed state: WontFix

[GoogleCodeExporter]

I gather from the license that third parties are permitted and encouraged to 
maintain binary packages, provided 
they take up the support responsibility? :-)

Original comment by [email protected] on 12 Jan 2007 at 5:19

[GoogleCodeExporter]

Why create something great like this and don't create a binary package? That's 
like
inviting all your friends to a great party and don't open the door :(.

Original comment by [email protected] on 12 Jan 2007 at 6:08

[GoogleCodeExporter]

Really. This is Mac OS X, not Linux. Not releasing binaries is pretty much 
equivalent
to not releasing at all!

Original comment by [email protected] on 12 Jan 2007 at 2:16

[GoogleCodeExporter]

Tough crowd. I'll see what we can do.

Original comment by [email protected] on 12 Jan 2007 at 5:49

• Changed state: Accepted

[GoogleCodeExporter]

I disagree; I don't think a package installer should be made available yet.
From what I gathered, this is not yet ready for mainstream usage. It needs more
testing, etc.
When most people agree that it's stable, then a binary installer could be made
available to reach the 'common mac user'. Until then, only 'early adopters' /
enthusiast should install this.

Original comment by guillaume.boudreau on 13 Jan 2007 at 12:54

[GoogleCodeExporter]

copy/pasting commands from a wiki page to install sucks ;)

Original comment by coder.cotton on 13 Jan 2007 at 3:31

[GoogleCodeExporter]

asingh, please don't be discouraged by the "demand" for a binary package.  I
personally would rather compile and package MacFUSE if it gives you and your 
team
more resources to develop and release incredible software like this.

As I continue to compile and package, should I update this ticket with the new 
files,
or would you prefer I take the packages off-site to something like afp548.com to
ensure everyone understands google is not releasing and supporting these 
community
binary packages?

Thanks again for MacFUSE.  I was more excited by your presentation than the 
keynote.  =)

Original comment by [email protected] on 13 Jan 2007 at 7:26

[GoogleCodeExporter]

asingh, please don't be discouraged by the "demand" for a binary package.  I
personally would rather compile and package MacFUSE if it gives you and your 
team
more resources to develop and release incredible software like this.

As I continue to compile and package, should I update this ticket with the new 
files,
or would you prefer I take the packages off-site to something like afp548.com to
ensure everyone understands google is not releasing and supporting these 
community
binary packages?

Thanks again for MacFUSE.  I was more excited by your presentation than the 
keynote.  =)

Original comment by [email protected] on 13 Jan 2007 at 7:28

[GoogleCodeExporter]

Here's a 0.1.0b006 Package.  I'll be naming all further packages "MacFUSE.pkg" 
to
prevent a ton of folders being created in /Library/Receipts.  I've also changed 
the
package to recommend, but not require a restart and attempt to unload the kext 
to
ease upgrades.

Original comment by [email protected] on 13 Jan 2007 at 7:49

Attachments:

• MacFUSE-0.1.0b006-1.pmproj
• MacFUSE-0.1.0b006-1.dmg
• MacFUSE-0.1.0b006-1.dmg.asc

[GoogleCodeExporter]

I'm unable to successfully download the MacFUSE Package uploaded by jeff.
It fails before fully downloading it. I would suggest moving the package to 
another
server and giving it a proper home, since the binaries are going to change 
regularly
(and this is not it's home)...

Original comment by [email protected] on 14 Jan 2007 at 3:36

[GoogleCodeExporter]

We're providing an *unsupported* package based installer. I'm leaving the 
tarball in
place too for the time being. Please try out the installer and verify that it 
works.

Original comment by [email protected] on 15 Jan 2007 at 8:24

[GoogleCodeExporter]

Hello, I do not understand why you instal fuse.kext in 
/System/Library/Extensions. This folder is reserved for 
Apple usage, and you can use the /Library/Extensions folder that is reserved 
for third-party extensions.
Is there a special reason?

Original comment by [email protected] on 15 Jan 2007 at 12:21

[GoogleCodeExporter]

While /System/Library is indeed generally reserved for Apple's use, there is no 
third-party equivalent for 
/System/Library/Extensions in particular. /Library/Extensions is non-standard.

http://daringfireball.net/2003/08/the_one_and_only_mac_os_x_extensions_folder 
pretty much says it all; 
although three and a half years old now, things haven't really changed since. 
XNU still, to my knowledge, only 
looks in that one directory. The mailing list post Gruber links to ( 
http://lists.apple.com/archives/darwin-
development/2002/Dec/msg00083.html ), while yet another year older, also 
contains some more insight.

So, the special reason, in essence, is that there is no true alternative.

Some vendors (including yours truly) do use /Library/Extensions, but only 
through manually loading those 
extensions. Since FUSE is more general-purpose, it ought to be available for 
automatic loading, and that 
makes /System/Library/Extensions the only viable location.

Original comment by [email protected] on 15 Jan 2007 at 12:29

[GoogleCodeExporter]

Thank you for this explication. I better understand now.

Original comment by [email protected] on 15 Jan 2007 at 6:33

[GoogleCodeExporter]

There is a package-based installer now.

Original comment by [email protected] on 15 Jan 2007 at 11:14

• Changed state: Fixed

[GoogleCodeExporter]

The package based installer is great.  Thanks.  Gorgeous icons too; the extra 
touch
is nice.

Original comment by [email protected] on 22 Jan 2007 at 9:46