search

bispawel / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

MacFUSE should have package-based installer #1

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
For a Mac OS X product, especially one that will install components in several 
locations, standard 
practice is to distribute with a package-based installer. Aside from user 
convenience, it allows the 
use of tools such as Pacifist to examine the contents prior to installation. I 
know you're aware of 
this, but I figured I'd post this to track the issue.

Thanks for the excellent work - I look forward to more Linux-based filesystems 
being ported to 
this.

Original issue reported on code.google.com by joshua.o...@gmail.com on 11 Jan 2007 at 8:34

GoogleCodeExporter commented 8 years ago 
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 chrisf.g...@gmail.com on 11 Jan 2007 at 9:24

GoogleCodeExporter commented 8 years ago 
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 mccune.j...@gmail.com on 11 Jan 2007 at 9:35

Attachments:

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

Original comment by chrisf.g...@gmail.com on 11 Jan 2007 at 9:40

GoogleCodeExporter commented 8 years ago 
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 si...@gmail.com on 12 Jan 2007 at 5:13

GoogleCodeExporter commented 8 years ago 
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 chucker...@gmail.com on 12 Jan 2007 at 5:19

GoogleCodeExporter commented 8 years ago 
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 bodo.tas...@gmail.com on 12 Jan 2007 at 6:08

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

Original comment by paracel...@gmail.com on 12 Jan 2007 at 2:16

GoogleCodeExporter commented 8 years ago 
Tough crowd. I'll see what we can do.

Original comment by si...@gmail.com on 12 Jan 2007 at 5:49

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
copy/pasting commands from a wiki page to install sucks ;)

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

GoogleCodeExporter commented 8 years ago 
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 mccune.j...@gmail.com on 13 Jan 2007 at 7:26

GoogleCodeExporter commented 8 years ago 
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 mccune.j...@gmail.com on 13 Jan 2007 at 7:28

GoogleCodeExporter commented 8 years ago 
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 mccune.j...@gmail.com on 13 Jan 2007 at 7:49

Attachments:

GoogleCodeExporter commented 8 years ago 
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 adam.q.salter@gmail.com on 14 Jan 2007 at 3:36

GoogleCodeExporter commented 8 years ago 
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 si...@gmail.com on 15 Jan 2007 at 8:24

GoogleCodeExporter commented 8 years ago 
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 jddu...@gmail.com on 15 Jan 2007 at 12:21

GoogleCodeExporter commented 8 years ago 
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 chucker...@gmail.com on 15 Jan 2007 at 12:29

GoogleCodeExporter commented 8 years ago 
Thank you for this explication. I better understand now.

Original comment by jddu...@gmail.com on 15 Jan 2007 at 6:33

GoogleCodeExporter commented 8 years ago 
There is a package-based installer now.

Original comment by si...@gmail.com on 15 Jan 2007 at 11:14

GoogleCodeExporter commented 8 years ago 
The package based installer is great.  Thanks.  Gorgeous icons too; the extra 
touch
is nice.

Original comment by mccune.j...@gmail.com on 22 Jan 2007 at 9:46