[arch-general] [arch-dev-public] [arch-projects] [HEADSUP] udevd moved out of PATH

[Myra Nelson]

On Tue, Oct 11, 2011 at 08:32, Dan McGee <dpmcgee at gmail.com> wrote:

> On Tue, Oct 11, 2011 at 8:14 AM, Tom Gundersen <teg at jklm.no> wrote:
> > On Tue, Oct 11, 2011 at 11:44 PM, Dan McGee <dpmcgee at 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.
>
> 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 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
> 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
>

I'm not a dev but would like to stick my two cents in here anyway.  The
following statement by Dan McGee highlights some of my concerns with a lot
of distros and why I chose Arch to begin with.

 "At least I see it as a negative; why are we making things harder on the
user to have control of their system?"

With Arch I still have control of my machine. I do not care for what, IMHO,
is the drive to appease the corporate user types who insist everyones'
machine look the same and force everyone into a common way of doing things.
 It may be great for the office, but not for other users. Like Dan I'm
coming accross as old and resistant to change. Change is good and necessary
unless it's change for changes' sake. I realize the Arch way dictates
minimal patching and staying current with upstream, but what happens if
upstream goes the wrong direction?

I had a steep learning curve because I wanted to use Arch and I still have a
long way to go, but at least I remember how to set up, maintain and use a
computer again. I still have to look/ask for help ocassionally, but I'm
getting there. Please keep Arch simple and useable.

Myra

-- 
Life's fun when your sick and psychotic!