r21623 is a seemingly innocuous commit, but it provides MacFUSE support. Hooray! Go read the commit message on that thing if you want the details. It's a real monster of a message, and provides all the juicy details you want. If you want to add more filesystems, take a gander at the sshfs port. It should provide the template you need. If you have any questions, just ask me. Probably tomorrow I will take a look at adding some of the more popular ones, starting with ntfs-3g. That said, I'm actually pretty unsure as to what filesystems are popular outside of sshfs and ntfs-3g, so if you have any suggestions, send an email my way. Word of warning: if you have fusefs installed, and you've mounted a FUSE filesystem at least once during this power-on session, uninstalling will leave the kext loaded into kernelspace. This is not, strictly speaking, *dangerous*, but it might cause some confusion if you proceed to then install a different version (confusion being the old one is still loaded, so the new one won't be). The simple solution is to reboot, the complicated solution is to make sure no FUSE filesystems are mounted and run `sudo kextunload -b com.google.filesystems.fusefs`. When MacFUSE puts out another release and I update the portfile. I'll probably stick a message in there somewhere instructing people to reboot if they're upgrading their fusefs installation. Ideally this would actually go into a post-deactivate phase, but since such a phase doesn't actually exist at the moment, the best place is probably a post-activate. Theoretically it could even query to see if the kext is loaded in pre-activate, and spit out the message in post- activate telling the user that they have to reboot. If you have any thoughts on this matter, well, you know what to do ;) -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
Hey Kevin! Seeing we could easily grow the fuse category with a rather similar template for every port in it other than the two base fusefs and libfuse ports, or so I think, this would seem like great candidate for a new PortGroup code a la perl PortGroup, ruby, aqua, etc... Do I have enough drag to encourage you to write the base code for the group? It shouldn't be too hard for you to take a look into the existing groups in base/src/port1.0/resources/group/ and figuring out the requirements and syntax ;-) Once written, the sshfs port could be rewritten as an initial test against the group before other ports leverage it... up for inclusion in 1.4 if time & testing permits, woot! But other than that, MacFUSE PortGroup or not, kudos to you for bringing this into our repo, I'm sure many will have lots of thanking words for you, here are mine! Regards,.... -jmpp On Jan 31, 2007, at 2:02 AM, Kevin Ballard wrote:
r21623 is a seemingly innocuous commit, but it provides MacFUSE support. Hooray!
Go read the commit message on that thing if you want the details. It's a real monster of a message, and provides all the juicy details you want.
If you want to add more filesystems, take a gander at the sshfs port. It should provide the template you need. If you have any questions, just ask me.
Probably tomorrow I will take a look at adding some of the more popular ones, starting with ntfs-3g. That said, I'm actually pretty unsure as to what filesystems are popular outside of sshfs and ntfs-3g, so if you have any suggestions, send an email my way.
Word of warning: if you have fusefs installed, and you've mounted a FUSE filesystem at least once during this power-on session, uninstalling will leave the kext loaded into kernelspace. This is not, strictly speaking, *dangerous*, but it might cause some confusion if you proceed to then install a different version (confusion being the old one is still loaded, so the new one won't be). The simple solution is to reboot, the complicated solution is to make sure no FUSE filesystems are mounted and run `sudo kextunload -b com.google.filesystems.fusefs`.
When MacFUSE puts out another release and I update the portfile. I'll probably stick a message in there somewhere instructing people to reboot if they're upgrading their fusefs installation. Ideally this would actually go into a post-deactivate phase, but since such a phase doesn't actually exist at the moment, the best place is probably a post-activate. Theoretically it could even query to see if the kext is loaded in pre-activate, and spit out the message in post-activate telling the user that they have to reboot. If you have any thoughts on this matter, well, you know what to do ;)
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
I'll definitely look into it, thanks for the suggestions. On Jan 31, 2007, at 7:16 AM, Juan Manuel Palacios wrote:
Hey Kevin! Seeing we could easily grow the fuse category with a rather similar template for every port in it other than the two base fusefs and libfuse ports, or so I think, this would seem like great candidate for a new PortGroup code a la perl PortGroup, ruby, aqua, etc...
Do I have enough drag to encourage you to write the base code for the group? It shouldn't be too hard for you to take a look into the existing groups in base/src/port1.0/resources/group/ and figuring out the requirements and syntax ;-) Once written, the sshfs port could be rewritten as an initial test against the group before other ports leverage it... up for inclusion in 1.4 if time & testing permits, woot!
But other than that, MacFUSE PortGroup or not, kudos to you for bringing this into our repo, I'm sure many will have lots of thanking words for you, here are mine!
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 31 janv. 07, at 07:02, Kevin Ballard wrote:
r21623 is a seemingly innocuous commit, but it provides MacFUSE support. Hooray!
Great, thanks for your contribution :-) I just want to let you know that even after syncing, fuse was not recognized. My bet (sole intuition) is the problem came from the new top-level category added. $ port search fuse libconfuse devel/libconfuse 2.5 libConfuse is a configuration file parser library zope-cmfusertracktool zope/zope-cmfusertracktool 1.1 User tracking product for CMF Zope sites No trace of fusefs :-( I had to manually "sudo portindex" in order to be able to install it. Do other people had the same problem ? Regards. Cédric Luthi
On Jan 31, 2007, at 12:04 PM, Cédric Luthi wrote:
$ port search fuse
port search uses the portindex
No trace of fusefs :-(
I had to manually "sudo portindex" in order to be able to install it.
portindex gets updated 2x a day
Do other people had the same problem ?
only if they are impatient ;-) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (4)
-
Cédric Luthi
-
Daniel J. Luke
-
Juan Manuel Palacios
-
Kevin Ballard