Created attachment 307071 [details] modifed ebuild sys-fs/udev-182-r1 I propose to add a special flag when you use a separate usr partition, I have prepared for the ebuild revision, which added the flag "usr" to override "--bindir" and "--libdir" in / bin and / Lieb, respectively. I attach a patch for the script "configure" to build udev, because "kmod" and "libkmod" also must be located in "/ bin" and "/ lib", a modified ebuild kmod also attached.
Created attachment 307073 [details, diff] patch for udev-182 configure
Created attachment 307075 [details] modifed ebuild sys-apps/kmod-7-r1
Created attachment 307083 [details, diff] udev-182-r2.ebuild.patch (In reply to comment #0) > Created attachment 307071 [details] > modifed ebuild sys-fs/udev-182-r1
Created attachment 307085 [details, diff] kmod-7.ebuild.patch
If you have a separate /usr partition, you need to use an initramfs to pre-mount /usr when you boot your system [1]. Also, moving all of this to /bin and /lib is counter-productive since we are working toward implementing the /usr merge [2]. [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken [2] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
The fact that the initrd is needed if the "/ usr" my system on a separate partition I'm aware of. But right now I do not use initrd, but "/ usr" a separate section, all necessary for the normal running of the system is in the kernel and root partition. I do not like to impose on the use of something, when you can do without it, so I think it should be allowed to choose the needed initrd in particular or not. It's one of the basic principles of "Linux" and "Gentoo", in particular. To implement what I suggested is not difficult, nor what it will not cause complications. Added flag for default is not active, if necessary, it will be possible to activate and get a bootable system without "initrd", later, after the transition to a new file system hierarchy flag can be removed, or left to the systems that were previously installed, and where not made these changes. The decision to merge the "/bin", "/sbin", "/lib," and "/usr/bin", "/USR/sbin", "/USR/lib" final? Unfortunately I have not seen the course of making a decision on this matter, I would like to see. Links "/bin" -> "/usr/bin" and others will be created?
(In reply to comment #6) > The decision to merge the "/bin", "/sbin", "/lib," and "/usr/bin", > "/USR/sbin", "/USR/lib" final? > Unfortunately I have not seen the course of making a decision on this > matter, I would like to see. There were lengthy discussions about this issue on the gentoo-dev mailing list. Multiple upstream projects and linux distributions are making changes to support doing this. Especially since upstream projects are starting to assume that systems are set up this way, doing anything differently is going to cause a lot of extra work for us, such as maintaining custom patches. Also, there are advantages to doing this; see the link above about "The Case for the /usr Merge." > Links "/bin" -> "/usr/bin" and others will be created? That is correct. Once we have everything moved, /bin, /sbin and /lib* will become symbolic links to the same directory names under /usr. This actual migration process will not start until >=udev-182 is stable. A news item will be sent out detailing the process just before that happens. So, again, adding this use flag would go against where multiple linux distributions and upstream projects are moving, so it would be counter-productive.
(In reply to comment #6) > The fact that the initrd is needed if the "/ usr" my system on a separate > partition I'm aware of. But right now I do not use initrd, but "/ usr" a > separate section, all necessary for the normal running of the system is in > the kernel and root partition. I do not like to impose on the use of > something, when you can do without it, so I think it should be allowed to > choose the needed initrd in particular or not. It's one of the basic > principles of "Linux" and "Gentoo", in particular. To implement what I > suggested is not difficult, nor what it will not cause complications. Added > flag for default is not active, if necessary, it will be possible to > activate and get a bootable system without "initrd", later, after the > transition to a new file system hierarchy flag can be removed, or left to > the systems that were previously installed, and where not made these changes. The philosophical argument is lost on this one. Fedora owns the Linux community now, since if they can dictate this to the Linux community, they'll dictate other stuff in the future. Just watch. Your only choice is to drop udev entirely until such a time when you rebuild the system to merge / and /usr. If you run a simple setup and don't have anything fancy going on (i.e., you're using standard filesystems like ext3/ext4), then you can replace udev with mdev and keep your current setup. I hate it as much as a lot of other people do, but the backers of this move are adamant that it's the RightWay(TM) and the OnlyWay(TM). See this Wiki link on replacing udev with mdev: https://wiki.gentoo.org/wiki/Mdev
> The philosophical argument is lost on this one. Fedora owns the Linux > community now, since if they can dictate this to the Linux community, > they'll dictate other stuff in the future. Just watch. > > Your only choice is to drop udev entirely until such a time when you rebuild > the system to merge / and /usr. If you run a simple setup and don't have > anything fancy going on (i.e., you're using standard filesystems like > ext3/ext4), then you can replace udev with mdev and keep your current setup. > > I hate it as much as a lot of other people do, but the backers of this move > are adamant that it's the RightWay(TM) and the OnlyWay(TM). > > See this Wiki link on replacing udev with mdev: > https://wiki.gentoo.org/wiki/Mdev I'm glad you understand me. I myself do not particularly like the the merger "/ bin" to "/ usr / bin" and others. Thanks for the url about the "mdev", may follow the advice, but most likely will stay on udev, setting it to me later with a modified "ebuild", with the flag of "usr". I offered to make these changes, which would have had a choice, polnsotyu refuse to "udev" I do not plan to. On our forum (my country) is also erupted over the swift merger of directories and the need to use initrd., So I made this offer. But once rejected my proposal will use a modified ebuild in a local overlay, perhaps someone from our user forum to follow my suggestion. But still sorry that was rejected.
As I hate this idiotic / -> /usr merges as well I started to work against it in my private overlay (poly-c). Just look at the udev and kmod ebuilds there. They should be a start for you to make the needed changes for getting a separate /usr partition running without hassle. Please keep in mind that I don't have a /usr partition and thus cannot do any tests. I merely wanna keep binaries where they belong and don't want to be part of this braindamaged / -> /usr move all our fedora-/systemd-fanboys are trying to impose on us.
(In reply to comment #9) > I'm glad you understand me. I myself do not particularly like the the merger > "/ bin" to "/ usr / bin" and others. Thanks for the url about the "mdev", > may follow the advice, but most likely will stay on udev, setting it to me > later with a modified "ebuild", with the flag of "usr". I offered to make > these changes, which would have had a choice, polnsotyu refuse to "udev" I > do not plan to. On our forum (my country) is also erupted over the swift > merger of directories and the need to use initrd., So I made this offer. > > But once rejected my proposal will use a modified ebuild in a local overlay, > perhaps someone from our user forum to follow my suggestion. > > But still sorry that was rejected. Constantly modifying udev isn't going to work for very long. The udev maintainers feel very strongly that the /usr merge is how things should have been from the start and will reject any patch that tries to change that. As new udev versions are released and as it gains new features, maintaining this will be come a lot trickier, too. Hopefully mdev will become its own project that aims to fill that gap for people with simple setups, but who knows right now. It itself is a bit of a hack, but it works and it negates the need for an initramfs until you start adding in things like LVM, encryption, etc. Now to just wait until dbus becomes a dependency for init to even run...
(In reply to comment #11) > Hopefully mdev will become its own project that aims to fill that gap for > people with simple setups, but who knows right now. It itself is a bit of a > hack, but it works and it negates the need for an initramfs until you start > adding in things like LVM, encryption, etc. The other concern with this mdev setup is that busybox will eventually migrate to /usr and when it does this will not work.
(In reply to comment #12) > (In reply to comment #11) > > Hopefully mdev will become its own project that aims to fill that gap for > > people with simple setups, but who knows right now. It itself is a bit of a > > hack, but it works and it negates the need for an initramfs until you start > > adding in things like LVM, encryption, etc. > > The other concern with this mdev setup is that busybox will eventually > migrate to /usr and when it does this will not work. Merging busybox as a static binary should mitigate this. We'll find out, though. Someone will think up a workaround, because I'm not rebuilding/reinstalling my entire system right now to align with a configuration change that I find pointless within our specific distribution (regardless of however much sense it might have in other distributions). Maybe I'm just getting old...
Created attachment 310109 [details, diff] patch for udev ebuild
Created attachment 310113 [details, diff] udev-182-r3.ebuild.patch Please delete previous attachment
Created attachment 310143 [details] udev-182-r3.patch
Attach a new version of the patch to udev-182-r3.ebuild, udev-182-r3.patch. With the following changes: - Instead of using the patch udev-182-separate_usr.patch use variable declarations 'KMOD_CFLAGS' and 'KMOD_LIBS' in src_configure() through the 'declare- x'; - In src_install() added check enable of the flag "usr" and create a link '/sbin/udevadm -> /usr/sbin/udevadm' if the flag "usr" is not used.
(In reply to comment #17) > Attach a new version of the patch to udev-182-r3.ebuild, udev-182-r3.patch. > With the following changes: > - Instead of using the patch udev-182-separate_usr.patch use variable > declarations 'KMOD_CFLAGS' and 'KMOD_LIBS' in src_configure() through the > 'declare- x'; > - In src_install() added check enable of the flag "usr" and create a link > '/sbin/udevadm -> /usr/sbin/udevadm' if the flag "usr" is not used. Attached*
(In reply to comment #12) i don't have any plans of moving busybox out of /bin (In reply to comment #13) the current busybox ebuild always installs a static copy at /bin/bb
(In reply to comment #19) > (In reply to comment #12) > > i don't have any plans of moving busybox out of /bin > > (In reply to comment #13) > > the current busybox ebuild always installs a static copy at /bin/bb The community seems ok about us doing the /usr merge (see the thread I sited on -project), so eventualy /bin will be a symlink to /usr/bin.
udev's hard requirement on recent kernels and specific filesystem layouts has seriously failed the community. i'll have a solution in busybox that'll work regardless of sep-/usr, merged-/usr, and doesn't require recent kernels or initramfs. udev's tight integration is producing unnecessarily fragile systems.
*** Bug 419871 has been marked as a duplicate of this bug. ***
