Alexander E. Patrakov wrote:
> This is a bug in udev, and should be fixed there.

And I was trying to decide before this commit whether I should have
posted it to -dev and gotten comments, or just committed it.  That's
what I get.  ;-)

> This has already been discussed on linux-hotplug-devel, and he
> (according to your message, falsely) assures that his scripts work
> with both methods: retry-uevents (recommended) and copy-rules
> (Debian-specific).

Hmm.  Well, I know it doesn't work with retry-uevents, because the
original uevent doesn't fail.  When the rule_generator scripts write to
/dev/.udev instead of /etc/udev/rules.d, they don't exit with a failed
status.  So there's nothing in the failed directory.  And "udevtrigger
--retry-failed" won't rerun these events.

We could just rerun "udevtrigger" and wait for everything again, but
that's a *horrible* hack; much worse than what this does.

> I propose to drop installation of the persistent helpers until this
> (and the wish about serial-based CDROM persistence and path_id-based
> network card persistence) is properly fixed upstream.

Yes, it should be fixed upstream.  (And I don't remember hearing about
issues, or claims that it works, before.  But maybe I hadn't subscribed
yet, or maybe I'm just forgetful.)  OTOH, if what we have works for the
moment, my first inclination is to just wait until they can get it fixed
upstream, and then yank out the workarounds we have in place.

But what's the reason behind your statement that we should drop this
until it works?  IMO the workarounds aren't *that* bad (even if they are
Debian-centric)...

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to