As discussed on the eudev issue: https://github.com/gentoo/eudev/issues/55 Summary: udev-init-scripts should propably implement a PREFIX make arg, so users who use prefixed openrc install could easily use the udev-initscripts. As of v 25, the udevd path is hardcoded, and I would propose a similar make system working as openrc uses, where also the header gets properly changed to fit eg /usr prefix install. The mentioned symlink check on the github issue could remain untouched if there was a PREFIX. Reproducible: Always Actual Results: User has to sed the /etc/init.d/udev to make it fit /usr prefix The 'problem' occurs for eg Arch Linux users https://github.com/udeved/pkgbuilds
Why are you installing openrc with PREFIX=/usr? If you have the /usr merge, /sbin = /usr/sbin because of the symlink, so there should not be a need to change the shebang line in /etc/init.d/udev.
William, I install it with /usr prefix, because soon, there will only be symlinks to /sbin & /bin binaries on arch linux. I was told by an Arch dev to take better care already for their /usr merge, and to install it to /usr. It made sense to me, since there is only a /lib symlink to /usr/lib in current Arch filesystem. The symlink line, as you say, is not a problem, but it'd be nice if the udevd binary non systemd path for the BINS would implement something like: @PREFIX@/sbin/udevd as well as #!@PREFIX@/sbin/runscript in the header. The 'problem' is nothing which can't be solved by other means, but I'd find it the most elegant way to simply have a PREFIX arg.
I forgot to mention, that this is mainly a problem if I use eudev. The systemd provided udev on Arch work well with the scripts, since the udevd binary is in /usr/lib/systemd. But as mentioned on the eudev issue on github, udevd needs to reside on /usr to trigger uevent properly. If eudev's udevd resides on /sbin while being a prefixed intall, uevent won't be triggered, but the scripts start.
If the location of the udevd binary is breaking udev event processing, that is an eudev issue and should be fixed there. You might try passing this to the OpenRC make file and see what happens since Archlinux has /sbin and /bin as directories still. In theory this should not break once the /usr merge is completed there also. make PREFIX=/usr SBINDIR=/sbin BINDIR=/bin ...
William, how do you mean, passing to openrc makefile? I already have prefix=/usr openrc make, just that there exists a /sbin/rc symlink to /usr/sbin/rc. Works perfectly for openrc provided runscripts, but any other runscript needs to have the header prefixed to be recognized by openrc as service. I could give an install with rc binary in /sbin a try, but this would be outdated as soon as Arch complete the merge .
I forgot, let aside the header prefix 'problem'. The easiest solution to udevd binary path would be to simple add: /usr/sbin/udevd to the bins. A fourth search path wouldn't hurt. On the plus side for a PREFIX, it'd apply to systemd paths too. But its rather a cosmetic issue.
(In reply to comment #6) > I forgot, let aside the header prefix 'problem'. > > The easiest solution to udevd binary path would be to simple add: > > /usr/sbin/udevd > > to the bins. A fourth search path wouldn't hurt. It would be redundant after the merge is complete though, because /sbin will point to /usr/sbin. > On the plus side for a PREFIX, it'd apply to systemd paths too. But its > rather a cosmetic issue. Again though, I don't think the prefix will be necessary after the /usr merge is complete because /sbin, /bin, etc will be symbolic links into /usr/*. I don't see those going away any time soon, because, for example, all shell scripts would have to have their shebang line changed from say: #!/bin/sh to #!/usr/bin/sh and I don't see that happening any time soon.
Yeah, the header should become redundant once the merge is complete. Anyway, the problem with the /sbin/udevd is that if it stays this way, eudev won't work with the scripts without tweaking on other linux, if eudev has prefix=/usr. I probably didn't get the point across, the problem is with the bin path for udevd. Sorry if that is the case. If you leave the bin path, udev-init-script will depend on a bug fix for eudev. Blueness said on the report, that he wasn't sure if he wants to 'fix' it, as it seems to be intended behaviour. Example: I use eudev with /usr prefix, but due to the eudev bug, I can't put the udevd in /sbin, as uevents won't trigger. However, I also cannot circumvent the problem, since the udevd symlink check line in udev runscript exists and prevents the /sbin/udevd symlink to be executed. The only way to make it work currently is to sed the path, and let it point to /usr/sbin/udevd. In summary, it is indeed a eudev originating problem, but, if I try to circumvent the problem, it becomes also a udev-init-scripts problem. My main question is, if you could provide a /usr/sbin/udevd search path too. The runscript does search for systemd-udevd in /lib/systemd and /usr/lib/systemd. Why not the same for plain udevd and only a /sbin path?
Don't worry too much about the shebang line. As said, its pure cosmetics to ask if the make could do the sed instead of the pkgbuild. I created a script which downloads and fixes these things for individual package runscripts. So it is not really a problem. :) Didn't want to confuse the true issue, that being the udevd path.
(In reply to comment #8) > Yeah, the header should become redundant once the merge is complete. > > Anyway, the problem with the /sbin/udevd is that if it stays this way, eudev > won't work with the scripts without tweaking on other linux, if eudev has > prefix=/usr. You shouldn't be installing eudev with prefix=/usr in the first place. Simply don't do that. Install to / in both type of systems, where the /usr-merge has been done, and where it hasn't been done. Where / and /usr are separate: udevd goes to /sbin/udevd Where / and /usr are merged: udev goes to /sbin/udevd, but will appear also as /usr/sbin/udevd because of the /sbin -> /usr/sbin symlink As in, it's not a bug in eudev, or udev-init-scripts. It's a bug in the packaging of eudev in your end. > My main question is, if you could provide a /usr/sbin/udevd search path too. This could be done, but I still don't see the point, why not package eudev correctly instead?
I agree with comment #10. Once the /usr merge is done, you will still be able to install with PREFIX=/. The /usr merge does not break being able to do that.
https://wiki.archlinux.org/index.php/Arch_Packaging_Standards While the guideline don't explicitly state a /usr prefix, any prototype or almost all pkgbuilds in their official repos are compiled with prefix=/usr They currently do symlinks to /sbin, and I am not sure if and when they will do the /usr/sin --> /sbin dir symlink. It looks to me, that compiling eudev atm on Arch without /usr prefix would violate the packaging policies of Arch as I end up with installing to /usr/lib anyway. But this also causes a problem, because the udev-rules reside on /usr/lib/udev, no matter with or without prefix.
(In reply to comment #12) > https://wiki.archlinux.org/index.php/Arch_Packaging_Standards > > While the guideline don't explicitly state a /usr prefix, any prototype or > almost all pkgbuilds in their official repos are compiled with prefix=/usr > > They currently do symlinks to /sbin, and I am not sure if and when they will > do the /usr/sin --> /sbin dir symlink. If they are going to do the /usr merge, they should create the symlinks from /bin->/usr/bin, /sbin->/usr/sbin. > It looks to me, that compiling eudev atm on Arch without /usr prefix would > violate the packaging policies of Arch as I end up with installing to > /usr/lib anyway. But this also causes a problem, because the udev-rules > reside on /usr/lib/udev, no matter with or without prefix. I don't know about eudev, but udev supports the --with-rootprefix and --with-rootlibdir switches which are very useful along with --prefix=/usr for non-usr-merged distros, which arch is, until they do the symlinks.
(In reply to comment #13) > (In reply to comment #12) > > https://wiki.archlinux.org/index.php/Arch_Packaging_Standards > > > > While the guideline don't explicitly state a /usr prefix, any prototype or > > almost all pkgbuilds in their official repos are compiled with prefix=/usr > > > > They currently do symlinks to /sbin, and I am not sure if and when they will > > do the /usr/sin --> /sbin dir symlink. > > If they are going to do the /usr merge, they should create the symlinks from > /bin->/usr/bin, /sbin->/usr/sbin. > > > It looks to me, that compiling eudev atm on Arch without /usr prefix would > > violate the packaging policies of Arch as I end up with installing to > > /usr/lib anyway. But this also causes a problem, because the udev-rules > > reside on /usr/lib/udev, no matter with or without prefix. > > I don't know about eudev, but udev supports the --with-rootprefix and > --with-rootlibdir switches which are very useful along with --prefix=/usr > for non-usr-merged distros, which arch is, until they do the symlinks. I already use rootprefix and prefix. Here is the build... https://github.com/udeved/pkgbuilds/blob/master/openrc-testing/eudev-git/PKGBUILD As I understand it, if I compile eudev without (root)prefix, it in fact gives me a prefix=/usr install, but binaries are installed /bin & /sbin. As if I would set sbindir and bindir in a prefix=/usr install. However, the udevd binary in /sbin creates a problem with eudev, but symlink /usr/sbin/udevd --> /sbin/udevd creates a problem with the udev runscript. Sorry for bugging you, but I think it would be best addressed by adding the /usr/sbin/udevd search path.
William, I think arch will take the same approach as Fedora. http://fedoraproject.org/wiki/Features/UsrMove Just that Arch don't have a /usr/lib64, which is merged in /usr/lib already. I guess this would be the final result on Arch: / |-- etc |-- usr | |-- bin | |-- sbin | |-- lib |-- run |-- var |-- bin -> usr/bin |-- sbin -> usr/sbin |-- lib -> usr/lib |-- lib64 -> usr/lib
(In reply to comment #14) > I already use rootprefix and prefix. > > Here is the build... > https://github.com/udeved/pkgbuilds/blob/master/openrc-testing/eudev-git/ > PKGBUILD > > As I understand it, if I compile eudev without (root)prefix, it in fact > gives me a prefix=/usr install, but binaries are installed /bin & /sbin. As > if I would set sbindir and bindir in a prefix=/usr install. Here is what I see in your build: --with-rootprefix=/usr \ --with-firmware-path="/usr/lib/firmware/updates:/usr/lib/firmware" Here is what they should be since arch has not implemented the /usr merge. --with-rootprefix= \ --with-rootlibdir=/lib \ --with-firmware-path="/lib/firmware/updates:/lib/firmware" Actually the --with-firmware-path option I show is the default value, so you don't really need to mention it at all. > However, the udevd binary in /sbin creates a problem with eudev, but symlink > /usr/sbin/udevd --> /sbin/udevd creates a problem with the udev runscript. The udevd runscript runs /sbin/udevd, which is where the binary will go for udev if you use the standard options. If eudev doesn't work with the udevd binary in /sbin, that is an issue with eudev and imo should be fixed. > Sorry for bugging you, but I think it would be best addressed by adding the > /usr/sbin/udevd search path. Like You show in comment #15, /sbin and /usr/sbin will be the same path once the /usr merge is done, so I don't see a need to add /usr/sbin/udevd to the script. Thanks, William
Thanks for the response. A last word, there is no /lib dir on Arch already, its a symlink, hence the prefix/rootprefix for eudev. The compile flags you recommend do not work in practice.
(In reply to comment #17) > Thanks for the response. > > A last word, there is no /lib dir on Arch already, its a symlink, hence the > prefix/rootprefix for eudev. > > The compile flags you recommend do not work in practice. If /lib points to /usr/lib, they should work fine. That's the whole idea of the /usr merge, to make /lib and /usr/lib be the same path. William
I just spoke with one of the eudev guys, and he agrees that this is not an issue with the scripts, and he is going to look into it more.
(In reply to comment #19) > I just spoke with one of the eudev guys, and he agrees that this is not > an issue with the scripts, and he is going to look into it more. Thanks a lot. I asked for the script "fix", since Blueness said on github that the eudev problem is important to keep in mind, but won't be fixed soon. It leaves users with no /lib a bit out in the rain currently, except they figured out that the script needs to run /usr/sbin/udevd and all is fine. It may shy off users on other Linux to try eudev and udev-init-scripts, it is difficult to mention eudev on a systemd distro forum. I don't want to say much on that here, but Arch's merge strategy is unfortunately not very well documented, like Suse or Fedora did. Thanks again.
