Re: [PATCH 1/2] Modernize udev rules

[Michael Tokarev <mjt@tls.msk.ru>]

11.02.2013 14:11, Thomas Bächler wrote:
> Am 11.02.2013 09:33, schrieb Michael Tokarev:
>> 11.02.2013 04:20, NeilBrown wrote:
>>> On Sat,  9 Feb 2013 18:48:38 +0100 Thomas Bächler
>>> <thomas@archlinux.org> wrote:
>>
>>>> -IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>>>> +IMPORT{builtin}="blkid"
>>
>> Does this has additional udev version constrain?
>> I mean, which is the minimum udev version to support this properly,
>> do we care?
>
> Udev relies on devtmpfs and thus does not create devices since version
> 176, therefore $tempnode is deprecated and only $devnode should be used
> ($tempnode seems to be around for compatibility, no idea if/when it will
> be dropped).
>
> The blkid builtin is also available since udev 176. In latest
> util-linux, the 'blkid -o udev' output is marked as deprecated, although
> Karel says it's not entirely going away for now.

Thank you for the explanation.

> Why do we care? We want correct udev rules ($tempnode vs. $devnode), and
> the using builtin is faster and less error-prone than calling an
> external tool (plus, it is used everywhere else in udev).
>
> As for compatibility: I see no reason why anyone would use a version of
> udev that is more than one year old (175) together with a mdadm version
> that is to be released in the future (3.2.7). If someone really wants
> that, they should be competent enough to adjust the udev rules for their
> local build.

Well, it was just a question.  Think about a distribution which is being
upgraded from one release to another, -- inter-package versioned dependencies
should be set correctly, so that the system will not be broken by upgrading
mdadm which relies on udev, but not upgrading udev.  It's a good idea to
note somewhere that the next release of mdadm will require at least udev
175.  That's about it.

Thank you!

/mjt
>

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html