[arch-projects] [HEADSUP] udevd moved out of PATH
Hi guys, This is mostly (only?) relevant for mkinitcpio and initscripts, so I did not cc arch-dev. /sbin/udevd will move to /lib/udev/udevd in udev-174. Since this is no longer in PATH we need to patch mkinitcpio and initscripts to take care of this and release them all together. I intended to do an initsrcritps release next week (when I get back home), but now I'll wait for udev-174 to be out. This should sort out mkinitcpio: <https://github.com/teg/mkinitcpio/commit/bbb3ae45931e8fb9a8a68f2dcc6c49cb3b928521>. Cheers, Tom
On Tue, Oct 11, 2011 at 05:51:56PM +1100, Tom Gundersen wrote:
Hi guys,
This is mostly (only?) relevant for mkinitcpio and initscripts, so I did not cc arch-dev.
/sbin/udevd will move to /lib/udev/udevd in udev-174. Since this is no longer in PATH we need to patch mkinitcpio and initscripts to take care of this and release them all together. I intended to do an initsrcritps release next week (when I get back home), but now I'll wait for udev-174 to be out.
This should sort out mkinitcpio: <https://github.com/teg/mkinitcpio/commit/bbb3ae45931e8fb9a8a68f2dcc6c49cb3b928521>.
That's half the solution -- as mentioned in the commit message, path_id and usb_id needs to be removed from install/udev as well. <rant> this seems like upstream is moving a binary for the sake of moving a binary. there's no rationale given in the commit message or the NEWS. grrrr. </rant> d
On Tue, Oct 11, 2011 at 5:10 AM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Oct 11, 2011 at 05:51:56PM +1100, Tom Gundersen wrote:
Hi guys,
This is mostly (only?) relevant for mkinitcpio and initscripts, so I did not cc arch-dev.
/sbin/udevd will move to /lib/udev/udevd in udev-174. Since this is no longer in PATH we need to patch mkinitcpio and initscripts to take care of this and release them all together. I intended to do an initsrcritps release next week (when I get back home), but now I'll wait for udev-174 to be out.
This should sort out mkinitcpio: <https://github.com/teg/mkinitcpio/commit/bbb3ae45931e8fb9a8a68f2dcc6c49cb3b928521>.
That's half the solution -- as mentioned in the commit message, path_id and usb_id needs to be removed from install/udev as well.
<rant> this seems like upstream is moving a binary for the sake of moving a binary. there's no rationale given in the commit message or the NEWS. grrrr. </rant>
This is really f***ing stupid of upstream. Why are they doing this outside of simply wanting to break everything? I'm not a fan of this as we are making upgrades way too fragile, not to mention moving what is very clearly a *binary* into a non-binary path, which is totally bogus. I know I've done `killall udevd && udevd --daemon` before to get the new version running; sounds like this is not going to work at all anymore. I would honestly pester upstream and have them justify the color of their hat this week; they seem obsessed with stupid incompatible changes like this. -1 from me on this whole change, upstream decision or not. -Dan
On Tue, Oct 11, 2011 at 11:44 PM, Dan McGee <dpmcgee@gmail.com> wrote:
This is really f***ing stupid of upstream.
Unlikely.
Why are they doing this outside of simply wanting to break everything?
What is breaking?
I'm not a fan of this as we are making upgrades way too fragile,
How? We always require udev, initscripts and mkinitcpio to be in sync, running udev should not be affected.
not to mention moving what is very clearly a *binary* into a non-binary path, which is totally bogus.
There are plenty of binaries in libexec (and there are plenty of non-binaries in bin), I don't see the problem.
I know I've done `killall udevd && udevd --daemon` before to get the new version running; sounds like this is not going to work at all anymore.
That does not sound like a good idea, you'll at least lose events.
I would honestly pester upstream and have them justify the color of their hat this week;
Unless you can come up with some real problems caused by this, I think that would be a waste of time. Even if they did not explain their reasoning very well this time, I'm pretty sure they have some, and won't revert just because some random people say "I don't like it".
-1 from me on this whole change, upstream decision or not.
-1 on what? What exactly are you proposing? -t
On Tue, Oct 11, 2011 at 8:14 AM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Oct 11, 2011 at 11:44 PM, Dan McGee <dpmcgee@gmail.com> wrote:
This is really f***ing stupid of upstream.
Unlikely.
Why are they doing this outside of simply wanting to break everything?
What is breaking? Everything I outlined below? Restarting a daemon, which shouldn't involve having to restart my computer to do so?
I'm not a fan of this as we are making upgrades way too fragile,
How? We always require udev, initscripts and mkinitcpio to be in sync, running udev should not be affected. Throw the filesystem package into that bucket too. What I meant to say is we have at times had this dependency happen, but it seems like every single upgrade as of late as absolutely required it. This was never the case a year ago. I realize I'm coming across as a old, resistant to change, pesky thorn in the side here, but we're doing things that are beginning to clash mightily with the Arch way here.
not to mention moving what is very clearly a *binary* into a non-binary path, which is totally bogus.
There are plenty of binaries in libexec (and there are plenty of non-binaries in bin), I don't see the problem. So let me make sure I understand here since the upstream commit wasn't linked- upstream moved it to libexec, which we normally move into to /usr/lib, but this particular binary is moving to /lib?
I know I've done `killall udevd && udevd --daemon` before to get the new version running; sounds like this is not going to work at all anymore.
That does not sound like a good idea, you'll at least lose events. Am I the only one that does this? Because the handy-dandy, still on my path `udevadm` command definitely doesn't have any sort of documented 'restart' function for those of us that don't like to reboot our installs once a week.
I would honestly pester upstream and have them justify the color of their hat this week;
Unless you can come up with some real problems caused by this, I think that would be a waste of time. Even if they did not explain their reasoning very well this time, I'm pretty sure they have some, and won't revert just because some random people say "I don't like it".
-1 from me on this whole change, upstream decision or not.
-1 on what? What exactly are you proposing? At the very least we should symlink this to the former location until
Are you sure about losing events? I thought the kernel cues them up if udevd isn't running. Maybe I need to add a `udevadm --exit` or something else to my incantation, I don't know. there is a udevadm that actually covers all of the use cases. Real problem #1- how do I restart this? #2 without having the path memorized? Re: upower, udisks, and polkit running out of libexec: I don't think this is seen as an advantage by many around here. At least I see it as a negative; why are we making things harder on the user to have control of their system? I also think having to hardcode *any* path to a binary (user-usable or not, WE still have to use it) like this is a real issue; what happens when the Kool-Aid color of the week moves it again? We continue to play along? -Dan
On Wed, Oct 12, 2011 at 12:32 AM, Dan McGee <dpmcgee@gmail.com> wrote:
What is breaking? Everything I outlined below? Restarting a daemon, which shouldn't involve having to restart my computer to do so?
By moving the binary to /lib upstream is trying to say that users should not touch it. Before it would be a reasonable assumption to make that you could manually restart udevd, now it is pretty clear that that is not supported.
Throw the filesystem package into that bucket too. What I meant to say is we have at times had this dependency happen, but it seems like every single upgrade as of late as absolutely required it. This was never the case a year ago. I realize I'm coming across as a old, resistant to change, pesky thorn in the side here, but we're doing things that are beginning to clash mightily with the Arch way here.
Speaking for myself, I'm just trying to update our packages to follow whatever upstream intended. If this could be done in a better way, let me know.
So let me make sure I understand here since the upstream commit wasn't linked- upstream moved it to libexec, which we normally move into to /usr/lib, but this particular binary is moving to /lib?
udev already keep their libexec stuff in /lib/udev. The reason that /usr/lib is not used is that udev is needed in early boot, which traditionally means that its files should not be in /usr. This is likely to change in the future so this would probably finally end up as /usr/lib/udev/udevd. It should be added that it does not matter to the user whether or not /lib or /usr/lib is used, these paths are only referenced once in mkinitcpio and once in initscripts, so we should manage to keep them in sync pretty easily. (And again, the user should never use these files, that's the whole point).
Am I the only one that does this? Because the handy-dandy, still on my path `udevadm` command definitely doesn't have any sort of documented 'restart' function for those of us that don't like to reboot our installs once a week.
Personally, I just make sure to only update before a reboot.
Are you sure about losing events? I thought the kernel cues them up if udevd isn't running. Maybe I need to add a `udevadm --exit` or something else to my incantation, I don't know.
I guess all you'll have to do is to shut down udevd like is done in mkinitcpio, and to start it again as is done in initscripts. This is not very elegant as the whole database is thrown away and recreated (and udevd will inherit crap from your session), but I think it should work. If used with systemd this should work much nicer, and restart will "just work" due to the socket handling.
-1 on what? What exactly are you proposing? At the very least we should symlink this to the former location until there is a udevadm that actually covers all of the use cases. Real problem #1- how do I restart this? #2 without having the path memorised?
I don't think we should add hacks to our packages to allow things that are not supported by upstream. The proper solution to this would be to file a feature request against udevadm, and in the meantime keep some script that does what you want (if it can be done).
Re: upower, udisks, and polkit running out of libexec: I don't think this is seen as an advantage by many around here. At least I see it as a negative; why are we making things harder on the user to have control of their system?
libexec means: upstream does not want the user to touch these binaries.
I also think having to hardcode *any* path to a binary (user-usable or not, WE still have to use it) like this is a real issue; what happens when the Kool-Aid color of the week moves it again? We continue to play along?
I'm happy to make sure initscripts and mkinitcpio are kept up-to-date with any future changes. -t
On Wed, Oct 12, 2011 at 1:47 AM, Tom Gundersen <teg@jklm.no> wrote:
I don't think we should add hacks to our packages to allow things that are not supported by upstream. The proper solution to this would be to file a feature request against udevadm, and in the meantime keep some script that does what you want (if it can be done).
If it turns out that restarting udevd is indeed the correct thing to do on upgrade, then we should just do that in the install script, which of course would be easy to keep in sync with whatever path udevd uses. -t
On Tue, Oct 11, 2011 at 10:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Oct 12, 2011 at 1:47 AM, Tom Gundersen <teg@jklm.no> wrote:
I don't think we should add hacks to our packages to allow things that are not supported by upstream. The proper solution to this would be to file a feature request against udevadm, and in the meantime keep some script that does what you want (if it can be done). Agreed- can you point me to the udev bug tracker so I can file said request?
If it turns out that restarting udevd is indeed the correct thing to do on upgrade, then we should just do that in the install script, which of course would be easy to keep in sync with whatever path udevd uses. Whoa. I might concede the rest of my argument, but we NEVER EVER EVER touch running programs on an Arch system. Ever.
-Dan
On Wed, Oct 12, 2011 at 2:03 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Oct 11, 2011 at 10:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Oct 12, 2011 at 1:47 AM, Tom Gundersen <teg@jklm.no> wrote:
I don't think we should add hacks to our packages to allow things that are not supported by upstream. The proper solution to this would be to file a feature request against udevadm, and in the meantime keep some script that does what you want (if it can be done). Agreed- can you point me to the udev bug tracker so I can file said request?
They don't have one. Any bugs go to the ML: <linux-hotplug@vger.kernel.org>.
If it turns out that restarting udevd is indeed the correct thing to do on upgrade, then we should just do that in the install script, which of course would be easy to keep in sync with whatever path udevd uses. Whoa. I might concede the rest of my argument, but we NEVER EVER EVER touch running programs on an Arch system. Ever.
Ok, as long as it works, that's fine by me. -t
On Wed, Oct 12, 2011 at 2:03 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Oct 11, 2011 at 10:01 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Oct 12, 2011 at 1:47 AM, Tom Gundersen <teg@jklm.no> wrote:
I don't think we should add hacks to our packages to allow things that are not supported by upstream. The proper solution to this would be to file a feature request against udevadm, and in the meantime keep some script that does what you want (if it can be done). Agreed- can you point me to the udev bug tracker so I can file said request?
They don't have one. Any bugs go to the ML: <linux-hotplug@vger.kernel.org>. Upstream says: we should be installing a symlink [1], which
On Tue, Oct 11, 2011 at 10:15 AM, Tom Gundersen <teg@jklm.no> wrote: potentially means we don't have to make changes elsewhere or tightly couple versions of our packages. On a related note from the same, for restarting, the `udevadm control --exit && udevd --daemon` process should work for restarting for us old farts not using systemd and not restarting our boxes once a week. I believe you could also run `udevadm trigger` if you were worried you missed any events. -Dan [1] http://marc.info/?l=linux-hotplug&m=131835335207882&w=2
On Wed, Oct 12, 2011 at 4:59 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Upstream says: we should be installing a symlink [1], which potentially means we don't have to make changes elsewhere or tightly couple versions of our packages.
Rereading the NEWS file I see that it does indeed suggest adding the symlink as an alternative to updating initscripts+mkinitcpio.
On a related note from the same, for restarting, the `udevadm control --exit && udevd --daemon` process should work for restarting for us old farts not using systemd and not restarting our boxes once a week. I believe you could also run `udevadm trigger` if you were worried you missed any events.
It should be pointed out that Kay also confirmed that restarting in this way would potentially lose events. I'm really not happy about adding a kludge whose only use-case is to do something that is kind of broken in the first place. That said, I guess we could do it to please the conservatives. At least in a transitional period, so we don't have to release all the packages at the same time (which I understood was one of the main objections). I'll mark it as deprecated though, and promise to remove it in the not too distant future. -t
Am 11.10.2011 17:03, schrieb Dan McGee:
If it turns out that restarting udevd is indeed the correct thing to do on upgrade, then we should just do that in the install script, which of course would be easy to keep in sync with whatever path udevd uses. Whoa. I might concede the rest of my argument, but we NEVER EVER EVER touch running programs on an Arch system. Ever.
I guess you haven't looked at the sysvinit post_upgrade recently.
Am 11.10.2011 14:44, schrieb Dan McGee:
I know I've done `killall udevd && udevd --daemon` before to get the new version running; sounds like this is not going to work at all anymore.
Not that I agree with all the funny path-moving here, but: Restarting udev was never supported.
On Tue, Oct 11, 2011 at 03:42:10PM +0200, Thomas Bächler wrote:
Am 11.10.2011 14:44, schrieb Dan McGee:
I know I've done `killall udevd && udevd --daemon` before to get the new version running; sounds like this is not going to work at all anymore.
Not that I agree with all the funny path-moving here, but: Restarting udev was never supported.
Since when? Upstream recommends that you stop udevd before upgrading udev (and you can watch its inotify watches freak out in the log file when you don't). killall might not be the cleanest way with 'udevadm control --exit' around nowadays, but I can't see why it wouldn't be supported to restart udev. d
On Tue, Oct 11, 2011 at 9:10 PM, Dave Reisner <d@falconindy.com> wrote:
That's half the solution -- as mentioned in the commit message, path_id and usb_id needs to be removed from install/udev as well.
Ah, I missed those. I guess they could be done in a separate commit, I'll try to remember.
<rant> this seems like upstream is moving a binary for the sake of moving a binary. there's no rationale given in the commit message or the NEWS. grrrr. </rant>
My guess at a rationale (I agree that it would be nice to put that in the change log): the user-facing interface to udev is udevadm, not udevd. A user should never need to call it, so it should not be in PATH. This is similar to how other daemons are stored in libexecdir and not in bindir (upower/udisks). Sounds fine by me. -t
participants (4)
-
Dan McGee
-
Dave Reisner
-
Thomas Bächler
-
Tom Gundersen