Hi! Could we get kmod and libkmod installed into / so we can then use it before mounting /usr on environments requiring so? Thanks!
+1 Please do so. There is no real reason to keep it in /usr other than that upstream wants it there which we can simply ignore as we are grown ups who can meet our own decisions.
-1, because this would involve moving xz-utils (liblzma) to / first time to setup initramfs, there is no way we can have everything required at / in the long run
# ls -l `which gzip` -rwxr-xr-x 1 root root 93856 Sep 24 10:33 /bin/gzip # ls -l `which bzip2` -rwxr-xr-x 1 root root 35200 Sep 24 10:12 /bin/bzip2 # We already have gzip and bzip2 in / so your argument is somewhat moot. Just move that tool and be done with it.
(In reply to comment #1) > +1 > > Please do so. There is no real reason to keep it in /usr other than that > upstream wants it there which we can simply ignore as we are grown ups who > can meet our own decisions. I'm looking at moving kmod. I have a revbump ready if we are going to do this. This upstream is not the udev/systemd upstream, so I asked about it there and it doesn't seem to bother them either way. @robbat2, since you are a udev maintainer, I want your thoughts as well. If we do this and stabilize it it means we can lastrights m-i-t since it has been deprecated anyway (In reply to comment #2) > -1, because this would involve moving xz-utils (liblzma) to / first This is correct; xz-utils will have to be moved to / if we do this. > time to setup initramfs, there is no way we can have everything required at > / in the long run This is also correct. Moving these two packages to / does not fix the separate /usr issue. See my post on -dev earlier about it. In a nutshell, we'll have to create a new tld, /share and copy parts of /usr/share to /share to make it work right.
I'm neutral on this, but I just want to make sure that everyone understands that it really doesn't fix the separate /usr issue.
Once xz-utils have been moved we also need to adjust sys-apps/man: $ grep "bin/xz" $(portageq envvar PORTDIR)/sys-apps/man/*.ebuild /var/portage/sys-apps/man/man-1.6f-r4.ebuild: COMPRESS=/usr/bin/xz /var/portage/sys-apps/man/man-1.6f-r5.ebuild: COMPRESS=/usr/bin/xz /var/portage/sys-apps/man/man-1.6g.ebuild: COMPRESS=/usr/bin/xz
This is not a solution to the broken consept of separate /usr, but I've moved liblzma in >= xz-utils-5.0.4-r1 and raised the dep in kmod's ebuild, and then moved kmod in >= 11-r2 and 9999 to /
There is a supported way of installing kmod in / which does not involv using gen_usr_ldscript. I have the patched ebuild on my other machine which I do not have access to until Wednesday. I am re-opening this to remind myselff to fix it then, or, if someone else on the udev team sees this first, you can join the #kmod channel and ask them.
(In reply to comment #8) > There is a supported way of installing kmod in / which does not > involv using gen_usr_ldscript. I have the patched ebuild on my other > machine which I do not have access to until Wednesday. > > I am re-opening this to remind myselff to fix it then, or, if someone > else on the udev team sees this first, you can join the #kmod channel > and ask them. Missed that configure switch. Lets try again. +*kmod-11-r3 (25 Nov 2012) + + 25 Nov 2012; Samuli Suominen <ssuominen@gentoo.org> +kmod-11-r3.ebuild, + kmod-9999.ebuild: + Use --with-rootlibdir= instead of gen_usr_ldscript wrt #443710 by William + Hubbs
Due to the move to '/', the libkmod.pc ends up being install in /lib/pkgconfig/ This results in libkmod not longer being discovered by pkg-config (which doesn't search in that directory). Which then results in udev-196 (for example) not finding libkmod at the configure step (despite being installed).
(In reply to comment #10) > Due to the move to '/', the libkmod.pc ends up being install in > /lib/pkgconfig/ > > This results in libkmod not longer being discovered by pkg-config (which > doesn't search in that directory). > > Which then results in udev-196 (for example) not finding libkmod at the > configure step (despite being installed). File a new bug with full build.log and emerge --info attached, because the .ebuild from gentoo-x86 (note: no crazy udev fork overlays) installs: --- /usr/ --- /usr/lib64/ --- /usr/lib64/pkgconfig/ >>> /usr/lib64/pkgconfig/libkmod.pc >>> /usr/lib64/libkmod.so -> ../../lib64/libkmod.so.2.2.1 So since this is working fine here, and all the code looks correct to me, we can't do much from already closed bug with lack of information. New issue. New bug. New full data like build.log Thank you.
