Packaging udev rules

[Igor Gnatenko]

Hello @all,

unfortunately I was not able to find updated information how to do that.

%{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
systemd, but there are more questions:

* Should %udev_rules_update be put into %post?
* Should %{?systemd_requires} be presented in spec? probably something else?

[Igor Gnatenko]

On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko  wrote:
> Hello @all,
>
> unfortunately I was not able to find updated information how to do that.
>
> %{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
> systemd, but there are more questions:
> Should %udev_rules_update be put into %post?
> Should %{?systemd_requires} be presented in spec? probably something else?

Looks like non of above:
(03:31:38 PM) dreisner: ignatenkobrain: no, it isn't
(03:32:12 PM) dreisner: assuming it does something silly like 'udevadm
control --reload'
(03:33:38 PM) ignatenkobrain: dreisner: yes, it does udevadm control
--reload ...
(03:33:47 PM) dreisner: not needed.
(03:34:01 PM) grawity: does udev pick up changes automatically now?
(03:37:38 PM) dreisner: it has for years
(03:38:08 PM) dreisner: used to do it by inotify. more recently it
just looks at timestamps prior to event processing, with some amount
of rate limiting.
> --
> -Igor Gnatenko

[Sérgio Basto]

On Sex, 2016-11-18 at 16:08 +0100, Igor Gnatenko wrote:
> On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko 
> wrote:
> > Hello @all,
> >
> > unfortunately I was not able to find updated information how to do
> > that.
> >
> > %{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
> > systemd, but there are more questions:
> > Should %udev_rules_update be put into %post?
> > Should %{?systemd_requires} be presented in spec? probably
> >
> > something else?
>
> Looks like non of above:
> (03:31:38 PM) dreisner: ignatenkobrain: no, it isn't
> (03:32:12 PM) dreisner: assuming it does something silly like
> 'udevadm
> control --reload'
> (03:33:38 PM) ignatenkobrain: dreisner: yes, it does udevadm control
> --reload ...
> (03:33:47 PM) dreisner: not needed.
> (03:34:01 PM) grawity: does udev pick up changes automatically now?
> (03:37:38 PM) dreisner: it has for years
> (03:38:08 PM) dreisner: used to do it by inotify. more recently it
> just looks at timestamps prior to event processing, with some amount
> of rate limiting.

hum, so use udevadm control --reload is deprecated ?

I review udev rules recently in one of my packages and systemd have 2
services: systemd-udevd.service and systemd-udev-trigger.service

trigger.service  have this command:
ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ;
/usr/bin/udevadm trigger --type=devices --action=add

and caused many problems with last systemd update (if I am correct) ,
so we shouldn't restart trigger.service service .

Anyway we should add some instructions in guidelines about this matter,
even if we don't need add nothing in %post etc
> > --
> > -Igor Gnatenko

[Jason L Tibbitts III]

> > > > > "SB" == Sérgio Basto  writes:

SB> Anyway we should add some instructions in guidelines about this
SB> matter, even if we don't need add nothing in %post etc

That would be great, but someone who knows all of the details would need
to actually provide a draft.  Or at least be willing to review something
random I put together, since I have no real understanding of the issues
here.

As far as I can tell, it's just "put udev rules in this directory" and
no scriptlets or anything else are needed.  In which case it's kind of
odd to have guidelines that tell you that you don't need to do anything,
but a section with a couple of short sentences won't hurt anything.

- J<

[Tom Hughes]

On 18/11/16 15:31, Sérgio Basto wrote:
> hum, so use udevadm control --reload is deprecated ?
>
> I review udev rules recently in one of my packages and systemd have 2
> services: systemd-udevd.service and systemd-udev-trigger.service
>
> trigger.service  have this command:
> ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ;
> /usr/bin/udevadm trigger --type=devices --action=add
>
> and caused many problems with last systemd update (if I am correct) ,
> so we shouldn't restart trigger.service service .

I think you're confusing two different things...

The first is whether udev loads the new rules - that should happen 
automatically but could be done manually with the "udevadm control 
--reload" command.

The second is whether those new/updated rules are applied to existing 
devices - they will always be applied when reacting to future 
add/change/remove events but you need to replay events with "udevadm 
trigger" to apply them to existing devices.

I suspect that the udev people would tell you it's a bad idea to do that 
though, as you unless you target the trigger very narrowly you are going 
to make all sorts of things happen. A global "add" trigger for example 
is basically pretending that all devices have suddenly been plugged in 
without being removed first.

Tom