Our ebuild moves rpc-statd into /sbin: # Install some client-side binaries in /sbin dodir /sbin mv "${ED}"/usr/sbin/rpc.statd "${ED}"/sbin/ || die but the installed service file rpc-statd.service still calls: ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS Is there a good reason to move this into /sbin, when upstream doesn't?
Linux Filesystem Hierarchy Standard define /sbin is for admin critical programs that must be runnable and present when system boot has gone wrong. And usr/sbin directory is use for non critical programs upstream decide to put that into /usr/sbin instead of the standard /sbin as define by LFHS Result : if /usr isn't early mount at boot, /usr/sbin is empty and nfs-utils is broken, making anyone using nfs to mount /usr as well, broken. Upstream (redhat) don't care as they broke the LFHS to symlink /sbin with /usr/sbin and use initramfs ; so /sbin or /usr/sbin for redhat distro will make no change. So : 1/ You can mount it /usr/sbin and it will always work with redhat but will break with other distro 2/ Or mount it in /sbin (that will makes no difference for redhat), but this times will not break on non-redhat distro like Gentoo. Now that you got the whole story, answering to ExecStart=/usr/sbin is easy. If you use 1/ without knowing that, you're lame and shouldn't code such thing ; or you use 1/ knowing exactly why you do that, and you are seeking the case it will break on non redhat distro. If you use 2/ then you are knowing why you do that, or just because you must do that for your distro or because you follow LFHS (or follow it when you have no real needs to break it for nothing). Thanks to the wise Gentoo dev that pickup option 2/ It show he isn't malicious and have perfect knowledge on howto handle that package. Does it answer you?
I was under the impression that we do not officially support separate /usr without an initramfs to bring it up. This seems to be another hack to try to keep supporting that setup. If the maintainer of this is going to stray from upstream just to keep supporting separate /usr w/o initramfs, he needs to follow through and fix all references to /usr/sbin/rpc.statd, that's what this bug is about.
You are missing that Council not officially supporting /usr... blahblah grant any devs right to not support it and so close bug that request it, it doesn't force dev to not support it if he wish. The maintainer may not have add himself the service file in the package, systemd maintainers might have done that ; so you shouldn't attack anyone that might be innocent first. Or just not attack devs (systemd or nfs-utils maintainers) that are doing the work for you no?
I'm not attacking anyone, I'm trying to get a bug fixed. Deviating from upstream in a way that breaks things is not good, I just want to make sure we are deviating for a good reason. For the most part, gentoo sticks to upstream to avoid these kinds of things. If the maintainers feel that nfs binaries living in /sbin is still important, then I'm fine with that. In the spirit of being "fine with that", here's an example patch that would fix it right up: --- nfs-utils-1.3.0.ebuild 2014-07-01 12:01:27.000000000 -0500 +++ nfs-utils-1.3.0-r1.ebuild 2014-07-22 09:15:00.763369404 -0500 @@ -60,7 +60,8 @@ sed \ -e "/^sbindir/s:= := \"${EPREFIX}\":g" \ -i utils/*/Makefile.am || die - + sed -e "/^ExecStart=/s:/usr/sbin:/sbin:" \ + -i systemd/rpc-statd.service || die eautoreconf }
Everyone could agree it's just a tiny bug that is easy fix (and thanks to other non systemd users you pickup fix to just correct the service file as it should be done), and thanks for other systemd users that will be happy to have a service running as it should. You see, you've made the two kind of users happy with your patch. While making patch to force rpc.statd be install in /usr/sbin would had put problem for some users for no benefits. And it's just a bug, i hardly think the guy that add the service file add it with the wrong path to break systemd in Gentoo, if he add it, it's to add better systemd support ; it's then hard to believe it's not a bug but malicious action. While it will be really more controversial if someone fix rpc.statd to run from /usr/sbin
I see now that our ebuild does correct this later in src_install, I need to investigate how/why I got it to install without this file being corrected. Having trouble reproducing now. Sorry for noise, will re-open if I can reproduce this again.
