[arch-projects] [HEADSUP] udevd moved out of PATH

[Tom Gundersen]

On Wed, Oct 12, 2011 at 12:32 AM, Dan McGee <dpmcgee at 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