After emailing with the author of zfs-fuse, he strongly recommends using the latest development sources (more stable, and they support much more recent pool versions). Attached is a live ebuild (and support files) to grab the sources from the "mercurial" source repo. Note that the patches had to change a bit, and this needs to be watched in the case of the live build... Also, I added code to unmount ZFS fs's before stopping. Two issues remain if USE="debug" is set: * The script returns failure even if the daemon starts * The execuatable stays running on stop (could be due to its being a shell script) (I tried different combinations of flags in the init.d script as well as leaving the --no-daemon switch on in the patch, but I never got it all to work right with debug.) Also, when debug is not set: * Using --make-pidfile seems to create a pid one off from real pid, so it doesn't work - also, the start returns a fail. Not sure what is going on. Removing this switch still works.
Created attachment 142561 [details] zfs-fuse-9999.ebuild
Created attachment 142563 [details] files/zfs-fuse-9999.rc
Created attachment 142564 [details] files/zfs-fuse-9999-fix_zdb_path.patch
Created attachment 142566 [details] files/zfs-fuse-9999-fix_zfs-fuse_path.patch
Created attachment 142567 [details] files/zfs-fuse-9999-fix_ztest_path.patch
On my system emerge fails because the patches don't work with the actual trunk (maybe changes in upstream code?).
It looks like upstream made some changes 5 days ago, so this may have invalidated the patches. It should be easy to fix them, and I will do this next time I try to upgrade ZFS-FUSE; if you want to have a go of it, post the patches if you are successful.
Created attachment 158343 [details, diff] Edited patch for latest commits
Anyone would know how to get the init script running? I keep getting * Caching service dependencies ... [ ok ] * Starting ZFS-FUSE ... * start-stop-daemon: did not create a valid pid in `/var/run/zfs-fuse.pi [ !! ]
Hey Joe, do you really feel fine with "live" ebuilds? especially where you mentioned that "i had to change a patch"-thing, I'd honestly recommend to bump snapshots of the head development tree (those proofed to compile and work) rather then leaving this experience up to the end user. Any impressions? To Pascal: did you check file permissions?
(In reply to comment #10) > Hey Joe, > > do you really feel fine with "live" ebuilds? especially where you mentioned > that "i had to change a patch"-thing, I'd honestly recommend to bump snapshots > of the head development tree (those proofed to compile and work) rather then > leaving this experience up to the end user. Christian, I agree. There is indeed an issue with live ebuilds that needs patches [that can break when the code changes]. I have not been following zfs-fuse development lately, so I do not know if the author still recommends the dev sources rather than snapshots. If not, then it is certainly better, at this point, to stick with the snapshots. For btrfs (another fs - I maintain those ebuilds), I have live ebuilds as well as release snapshots. This gives users the option of the live sources (but we do not have similar patch issues there). Also, I have hard-masked the live ebuilds, so regular users will not get them.
have a look at the portage CVS. i've tweaked the files a little, and package.mask'ed it. however, once found some reasonable good state, we could bump a snapshot for ~testing and stable, too. we've been using zfs-fuse for quite some time in some office-related production systems, this were quite stable for us, however, when should we go into `stable` masking anyway? (for such ebuilds) p.s.: please test the ebuild, if you can
(In reply to comment #9) > Anyone would know how to get the init script running? I keep getting > > * Caching service dependencies ... [ ok > ] > * Starting ZFS-FUSE ... > * start-stop-daemon: did not create a valid pid in `/var/run/zfs-fuse.pi [ !! > ] > shall be fixed, though. please test the ebuild in the latest tree (unmask =sys-fs/zfs-fuse-9999 before)
