>=sys-apps/systemd-198-r3 requires re-installation of any packages which install udev rules. We basically have 3 options for dealing with this: 1. Warn the user to reinstall everything (emerge -1 /lib/udev) 2. Move systemd to / 3. Go back to using sys-fs/udev
To expand on this: If the user does not re-install packages providing udev rules, I think this may cause boot problems if they are using things like mdadm or lvm for their system storage. As well, once systemd is installed, openrc will likely not function correctly due to the udev components being installed in different locations. I think option 2 and/or 3 may be better for us long-term and will be less likely to break user systems when people migrate from openrc to systemd.
Another possibility would be to patch systemd-udevd to load rules from both /usr/lib/udev/rules.d and /lib/udev/rules.d. Potentially, udev-init-scripts could also be patched to start udev from either / or /usr to resolve the openrc migration problem. I don't particularly care for this idea, but it would be the most transparent from a user perspective.
Here is a little more information on what happens. Since sys-fs/udev is installed in /, it looks for rules and helpers in /lib/udev and /lib/udev/rules.d. The bundled udev, since it is in /usr, looks for them in /usr/lib/udev/rules.d and /usr/lib/udev, but udev does NOT support looking in both /usr/* and /lib/*. Out of the three options Mike suggested in comment #1, I recommend option 2 or 3. This would also bring you closer to how upstream operates. The suggestion in comment #2, besides being a custom patch you would probably have to carry forever, also has another issue in that udev helpers are in both locations, so you would have to figure out which one to run.
I think of the whole discussion about the usr-merge as ridiculous: - Gentoo is a meta distribution - Gentoo has all the tools to implement user choice regarding usr-merge: We have all the eclasses to implement really complicated things like multilib and crossdev. But we can not insert three "usr" letters into a directory path? - Upstream doesn't mirgrate away from the /usr-merge, but says half-half is the most terrible way to go: udev-at-/ with systemd-at-/usr - All the goodies of systemd beyond booting, the use cases why Redhat is investing in systemd, are much easier with having the /usr-merge - Systemd is on its way to develop support for dracut building the perfect initrd - All the lazy-bones which have an extra /usr-partition but refuse to build an initrd: They argue with "Unix philosophy" against systemd. But the forget the Unix meaning of /usr: Unix-Software-Resources. Instead they misuse the /-root directory as a cheap rescue.
I have committed a patch in the morning but had to go before I could write a comment. I've made 198-r5 and 9999 use 'get_udevdir' from udev.eclass, which basically results in preferring whatever pkg-config gives us. This means that all the users who were able to install and run with udevdir on /usr successfully, will have it still there and not have to rebuild anything again. Users who will install those versions from now on will have udevdir on rootfs as it was with sys-fs/udev. The issue is temporarily fixed that way. The case of moving udevdir remains still open for future releases of systemd.
I'm going to answer this here, just for your information, but this really isn't the place to discuss the /usr merge (which I support actually). (In reply to comment #4) > - Upstream doesn't mirgrate away from the /usr-merge, but says half-half is > the most terrible way to go: udev-at-/ with systemd-at-/usr Yes, this is what I have been trying to advocate. If we are going to put udev in /, that's where systemd should go as well. > - All the lazy-bones which have an extra /usr-partition but refuse to build > an initrd: They argue with "Unix philosophy" against systemd. But the forget > the Unix meaning of /usr: Unix-Software-Resources. Instead they misuse the > /-root directory as a cheap rescue. This "translation" of "usr" is inaccurate. "usr" originally was what we call "home" currently.
For what's it worth =sys-fs/udev-199 should be our longterm stable version, it won't be changing at all -- except under situation serious bugs / regressions show up and minor patches need to be added Only waiting some 2-3 weeks, updating udev-guide.xml, write predictable network name news item, and filing a STABLEREQ for it, ditch 197* and 198* afterwards It would make sense to make ~sys-apps/systemd-199 use ~sys-fs/udev-199 if you want stability The _only_ reason there has been rapid changes in udev is that it's been as broken as people have said it has been (and not due to gentoo's packaging), anyone following git would know this As in, I consider 199 the final replacement for 171, otherwise 198 would have been it but 199 introduced the kernel commandline option net.ifnames=0 to disable the new networking scheme
And we can agree adding package.mask step in >=sys-fs/udev-200 bumps so systemd maintainers can then unmask it when they are ready.
(In reply to comment #7) > For what's it worth =sys-fs/udev-199 should be our longterm stable version, > it won't be changing at all -- except under situation serious bugs / > regressions show up and minor patches need to be added > Only waiting some 2-3 weeks, updating udev-guide.xml, write predictable > network name news item, and filing a STABLEREQ for it, ditch 197* and 198* > afterwards > It would make sense to make ~sys-apps/systemd-199 use ~sys-fs/udev-199 if > you want stability Honestly, I agree that it would make more sense for you to go back to working with us and having systemd use sys-fs/udev so that everyone has the same udev. You have a bug in your udev, bug #463376, which is going to cause extra issues when baselayout adopts the dialout group, as was our original plan, since this group is more of a system-wide group and is not udev specific. (In reply to comment #8) > And we can agree adding package.mask step in >=sys-fs/udev-200 bumps so > systemd maintainers can then unmask it when they are ready. I do not agree with this; adding newer udevs to p.mask is not necessary. All we have to do is be careful when we commit. I'm not going to go into a lot of detail on this bug, but I will just say that this really needs to be resolved, and we really need to think about how we can work together for the benefit of all of our users.
(In reply to comment #9) > (In reply to comment #7) > > For what's it worth =sys-fs/udev-199 should be our longterm stable version, > > it won't be changing at all -- except under situation serious bugs / > > regressions show up and minor patches need to be added > > Only waiting some 2-3 weeks, updating udev-guide.xml, write predictable > > network name news item, and filing a STABLEREQ for it, ditch 197* and 198* > > afterwards > > It would make sense to make ~sys-apps/systemd-199 use ~sys-fs/udev-199 if > > you want stability > > Honestly, I agree that it would make more sense for you to go back to > working with us and having systemd use sys-fs/udev so that everyone has the > same udev. You have a bug in your udev, bug #463376, which is going to cause > extra issues when baselayout adopts the dialout group, as was our original > plan, since this group is more of a system-wide group and is not udev > specific. What kind of issues? > (In reply to comment #8) > > And we can agree adding package.mask step in >=sys-fs/udev-200 bumps so > > systemd maintainers can then unmask it when they are ready. > > I do not agree with this; adding newer udevs to p.mask is not necessary. All > we have to do is be careful when we commit. > > I'm not going to go into a lot of detail on this bug, but I will just say > that this really needs to be resolved, and we really need to think about how > we can work together for the benefit of all of our users. What kind of benefit? I don't recall systemd users benefitting from the way udev is maintained in Gentoo at all.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > For what's it worth =sys-fs/udev-199 should be our longterm stable version, > > > it won't be changing at all -- except under situation serious bugs / > > > regressions show up and minor patches need to be added > > > Only waiting some 2-3 weeks, updating udev-guide.xml, write predictable > > > network name news item, and filing a STABLEREQ for it, ditch 197* and 198* > > > afterwards > > > It would make sense to make ~sys-apps/systemd-199 use ~sys-fs/udev-199 if > > > you want stability > > > > Honestly, I agree that it would make more sense for you to go back to > > working with us and having systemd use sys-fs/udev so that everyone has the > > same udev. You have a bug in your udev, bug #463376, which is going to cause > > extra issues when baselayout adopts the dialout group, as was our original > > plan, since this group is more of a system-wide group and is not udev > > specific. > > What kind of issues? When baselayout adds the dialout group, it will be a system group (meaning the gid will be some number under 1000). Also, this group is not a systemd/udev specific group; it will be added to all gentoo systems. Because of what you have done, systemd users already have a dialout group, with a non-system-group gid. system-wide groups like bin, daemon, dialout, etc are in a special range of gids. Once you add a group, it is really hard for us to change the gid; I would recommend that you remove this group creation then have all of your systemd users delete the dialout group from their systems. baselayout is on all systems, so what we do there does affect your systemd users. > > (In reply to comment #8) > > > And we can agree adding package.mask step in >=sys-fs/udev-200 bumps so > > > systemd maintainers can then unmask it when they are ready. > > > > I do not agree with this; adding newer udevs to p.mask is not necessary. All > > we have to do is be careful when we commit. > > > > I'm not going to go into a lot of detail on this bug, but I will just say > > that this really needs to be resolved, and we really need to think about how > > we can work together for the benefit of all of our users. > > What kind of benefit? I don't recall systemd users benefitting from the way > udev is maintained in Gentoo at all. The benefit is that everyone has the same udev. Basically, you have bundled your own version of a base-system package inside the systemd package instead of giving the udev team the time to go revert a mistake they made. I believe I personally was asleep when this all happened, otherwise I would have definitely reverted the dropping of the service files in -r5.
(In reply to comment #11) > Because of what you have done, systemd users already have a dialout group, > with a non-system-group gid. system-wide groups like bin, daemon, dialout, > etc are in a special range of gids. Incorrect. enewgroup adds a group in the system GID range. $ grep dialout /etc/group dialout:x:23:root > > > (In reply to comment #8) > The benefit is that everyone has the same udev. Basically, you have bundled > your own version of a base-system package inside the systemd package instead > of giving the udev team the time to go revert a mistake they made. How is that a benefit? So far having the same udev resulted only in maintenance trouble, upgrades full of risk and fragmented packages. I don't recall a single user mentioning he's happy having external udev with systemd. > I believe I personally was asleep when this all happened, otherwise I would > have definitely reverted the dropping of the service files in -r5. Package.masking new udev & systemd versions would probably be good. But I think it is too late for that now.
(In reply to comment #12) > (In reply to comment #11) > > Because of what you have done, systemd users already have a dialout group, > > with a non-system-group gid. system-wide groups like bin, daemon, dialout, > > etc are in a special range of gids. > > Incorrect. enewgroup adds a group in the system GID range. > > $ grep dialout /etc/group > dialout:x:23:root But what happens in baselayout if we do s/uucp/dialout/ in the master group files? That's what I need to find out from vapier in the related bug. How will this change you have made affect our users? > > > > > (In reply to comment #8) > > The benefit is that everyone has the same udev. Basically, you have bundled > > your own version of a base-system package inside the systemd package instead > > of giving the udev team the time to go revert a mistake they made. > > How is that a benefit? So far having the same udev resulted only in > maintenance trouble, upgrades full of risk and fragmented packages. I don't > recall a single user mentioning he's happy having external udev with systemd. There is no technical reason for udev to be replaced at all when systemd is installed. Right now, if I install systemd and boot with OpenRc because I am not ready to switch to systemd yet, which I am supposed to be able to do, I run the risk of getting a different result because I don't have the same udev on my system that I did before I installed systemd. > > I believe I personally was asleep when this all happened, otherwise I would > > have definitely reverted the dropping of the service files in -r5. > > Package.masking new udev & systemd versions would probably be good. But I > think it is too late for that now. There would be no reason to p.mask new versions of anything, because all we would have to do is make sure systemd only pulled the versions of udev it needs. The last time I checked, this is very easy to do with RDEPEND in the systemd ebuild. Again, I'm asking you, let's coordinate our efforts, and not make our users suffer over this.
We'll reopen this if we're going to change the udevdir.
