This is an ebuild for the separated out unionfs-utils package. With 2.0, there is no standalone package for unionfs. The kernel and use code is separated. Reproducible: Always Marking major because there is no current way to work with 2.6.20 and 2.6.21 stable kernel releases patched with unionfs. Addition of this package will be will be very useful.
Created attachment 119724 [details] The ebuild for latest unionfs-utils package
Is it possible for non-dev to be a maintainer? I mean at least the bug-fixing part? sorta have a alt-dev list of people who can provide new ebuilds, fix bugs and deal with a dev who doesn't really have to devote as much time doing all that but instead just reviewing the work and merging it in. what say you?
(In reply to comment #2) > Is it possible for non-dev to be a maintainer? I mean at least the bug-fixing > part? > > sorta have a alt-dev list of people who can provide new ebuilds, fix bugs and > deal with a dev who doesn't really have to devote as much time doing all that > but instead just reviewing the work and merging it in. This is possible. Ask one of the kernel devs [1] about being a proxy maintainer for this package. Another more immediate option is to commit this ebuild to the Sunrise overlay [2] yourself until someone agrees to maintain it in the main Portage tree. [1] http://www.gentoo.org/proj/en/kernel/index.xml [2] http://overlays.gentoo.org/proj/sunrise
ok, got it reviewed by two people on #gentoo-sunrise and changes applied but I don't have access to sunrise overlay. The 'contact us' link in this FAQ doesn't work: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq#CanIhaveaccesstotheoverlay 'svn co http://overlays.gentoo.org/svn/proj/sunrise/sunrise' requires auth.
(In reply to comment #4) Talk to Jokey in #gentoo-sunrise, he's the lead now. He can give you access to svn and correct any broken links on the Sunrise site.
Thanks. Done. Just wanna comment that this is not the latest ebuild. I will post when its available in sunrise.
ok.This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/sys-fs/unionfs-utils/
Since unionfs is a kernel patch as of 2.x and will be in the mainline kernel soon, unionfs-utils seems to be an appropriate place for a unionfsmount init script (or perhaps baselayout is an even better place?). I've been working on a script so I'll post it here as soon as I figure some stuff out. The main problem I'm having is that one of my boxes has some unions composed of nfs-imported branches, so the unionfs mounting needs to take place *after* /etc/init.d/nfsmount, which in turn depends on /etc/init.d/net.eth1 (my wireless connection). This means /etc/init.d/localmount is executed much too early to attempt the unionfs mounts I need, so I can't put them in /etc/fstab and hence they should probably go in a /etc/conf.d/unionfsmount file. Can anyone think of a better way to go about this?
Created attachment 120632 [details] /etc/init.d/unionfsmount I have a cleaner solution that allows unionfs entries in /etc/fstab as normal. For each unionfs mount that requires netmount or nfsmount, append "_netdev" to its mount options in /etc/fstab and set the corresponding option in /etc/conf.d/unionfsmount. This will cause /etc/init.d/localmount to skip those mounts, and cause /etc/init.d/unionfsmount to handle their mounting after the network mounts are in place. (Be sure to `rc-update add unionfsmount default`.) unionfs entries in /etc/fstab that don't have the "_netdev" option will get mounted by /etc/init.d/localmount.
Created attachment 120633 [details] /etc/conf.d/unionfsmount Here's the conf.d file.
Do we need to get these reviewed by at least one more person? I will include them and change the ebuild in sunrise once I get confirmation that these are reviewed and don't screw someone's system. Alex, just being cautious here. They look clean to me.
(In reply to comment #11) > Do we need to get these reviewed by at least one more person? I will include > them and change the ebuild in sunrise once I get confirmation that these are > reviewed and don't screw someone's system. Alex, just being cautious here. They > look clean to me. Yeah that's why I posted them here first... these really should be reviewed by at least one Gentoo dev with a decent knowledge of baselayout stuff, even before they're put in Sunrise. Hopefully a member of the teams CC'ed on this bug can help. ;)
BTW you should now change this bug's Keywords field to "EBUILD, InOverlay" and put "[sunrise-overlay]" in the Status Whiteboard field.
Created attachment 120699 [details] /etc/init.d/unionfsmount The conf.d file as it stands is superfluous. The init script can check /etc/fstab for the necessary information in its place. This is safer too since it eliminates one avenue of potential errors caused by user misconfiguration. You'll notice $unionfs_netmounts is declared identically in different local scopes. For some reason when I tried to declare it just once in the global scope (even using `export`) its current value seems inaccessable to depend() even though start() can see it just fine. I think this is dependency cache related, though I'm not sure how to handle it. Also, I don't know how to ensure unionfsmount gets taken down automatically whenever netmount or nfsmount is stopped. A similar mechanism exists between the apache2 and mysql init scripts, but I haven't discovered how it ticks. This might also be dependency cache related. So this script's still a bit buggy.
Created attachment 120705 [details] /etc/init.d/unionfs-netmount Heh, after further consideration I think it's best to narrow this init script's purpose to netmount-mounted dependencies. This script seems to resolve all the issues mentioned above.
CC'ing base-system for advice/critique of the init script.
i dont see why an init.d script is needed at all as it should automatically get picked up by localmount/netmount init.d scripts
(In reply to comment #17) > i dont see why an init.d script is needed at all as it should automatically get > picked up by localmount/netmount init.d scripts I believe an illustration is in order here. First we'll boot with a normal unionfs consisting of local branches only, then move on to booting with an nfs-dependent unionfs mount. Booting with a /etc/fstab entry for a unionfs composed of only local branches: none /mnt/unionfs unionfs dirs=/home/shillelagh/localbranch1:/home/shillelagh/localbranch2 0 0 Results: Mounted perfectly by localmount in boot runlevel $ ls /mnt/unionfs testfile_localbranch1 testfile_localbranch2 ---------- /etc/fstab entry for nfs mounted by /etc/init.d/netmount in default runlevel: remotebox:/home/shillelagh/remotebranch1 /mnt/nfs nfs rw 0 0 $ ls /mnt/nfs testfile_remotebranch1 /etc/fstab entry for unionfs composed of the two local branches plus the above remote nfs branch: none /mnt/unionfs unionfs dirs=/home/shillelagh/localbranch1:/home/shillelagh/localbranch2:/mnt/nfs 0 0 Boot results: 1. The nfs fails to be included in the union mount: $ ls /mnt/unionfs testfile_localbranch1 testfile_localbranch2 2. No warning is given by netmount, indicating (as expected) that it doesn't see the unionfs entry in /etc/fstab as a network-dependent mount, and that unionfs was instead mounted by localmount. ---------- Modifying the above unionfs entry to add _netdev to the options: none /mnt/unionfs unionfs _netdev,dirs=/home/shillelagh/localbranch1:/home/shillelagh/localbranch2:/mnt/nfs 0 0 Boot results: Total failure. Neither the local branches nor the nfs get union mounted, yet no warnings are given. This indicates that neither localmount nor netmount attempted to handle the unionfs mount. ---------- When the above /etc/fstab entry is used with my unionfs-netmount script added to the default runlevel, we finally get the desired results: $ ls /mnt/unionfs testfile_localbranch1 testfile_localbranch2 testfile_remotebranch1
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
