[PATCH] udev: sync udev rules directories with systemd units directories

[William Hubbs]

=46rom: Micha=C5=82 G=C3=B3rny <***@gentoo.org>

This adds /usr/lib, /usr/local/lib, and /lib (if split-usr is enabled)
to the directories where udev searches for rules.d. This brings udev in
line with how systemd searches for units and it is also needed if
split-usr is enabled because other software packages currently install
rules in /lib/udev/rules.d.
---
src/udev/udev-rules.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index b5b54dd..784d25e 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1759,7 +1759,12 @@ struct udev_rules *udev_rules_new(struct udev *u=
dev, int resolve_names)
=20
rules->dirs =3D strv_new(TEST_PREFIX SYSCONFDIR "/udev/rules.d=
",
TEST_PREFIX "/run/udev/rules.d",
+ TEST_PREFIX "/usr/local/lib/udev/rules.=
d",
TEST_PREFIX UDEVLIBEXECDIR "/rules.d",
+ TEST_PREFIX "/usr/lib/udev/rules.d",
+#ifdef HAVE_SPLIT_USR
+ TEST_PREFIX "/lib/udev/rules.d",
+#endif
NULL);
if (!rules->dirs) {
log_error("failed to build config directory array");
--=20
1.7.8.6

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

[Kay Sievers]

This adds /usr/lib, /usr/local/lib, and /lib (if split-usr is enabled=

)

to the directories where udev searches for rules.d. This brings udev =

in

line with how systemd searches for units and it is also needed if
split-usr is enabled because other software packages currently instal=

l

rules in /lib/udev/rules.d.
---
src/udev/udev-rules.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index b5b54dd..784d25e 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1759,7 +1759,12 @@ struct udev_rules *udev_rules_new(struct udev =

*udev, int resolve_names)

rules->dirs =3D strv_new(TEST_PREFIX SYSCONFDIR "/udev/rules=

=2Ed",

TEST_PREFIX "/run/udev/rules.d",
+ TEST_PREFIX "/usr/local/lib/udev/rule=

s.d",

Udev will *never* look in /usr/local, that is no place for
system-level software. My take on this is: early boot has absolutely
zero business in /usr/local.

I see that you just want to sync this, but I will not allow /usr/local
happen to udev. It makes no sense, does not solve any problem, creates
nothing but needless issues with custom setups and custom mounts
(which are not uncommon) on /usr/local that are better avoided.

I tried several times to talk Lennart out of that nonsense, but wasn't
successful so far. :)

TEST_PREFIX UDEVLIBEXECDIR "/rules.d"=

,

+ TEST_PREFIX "/usr/lib/udev/rules.d",
+#ifdef HAVE_SPLIT_USR
+ TEST_PREFIX "/lib/udev/rules.d",
+#endif

I have no problem with that, even when I think it's the wrong way to
do these things. It just creates mess, that is much bigger than the
split-usr ever was. But we have it in systemd, and there is no real
argument for me to make against it.

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

[William Hubbs]

Post by Kay Sievers
Udev will *never* look in /usr/local, that is no place for
system-level software. My take on this is: early boot has absolutely
zero business in /usr/local.
I see that you just want to sync this, but I will not allow /usr/local
happen to udev. It makes no sense, does not solve any problem, creates
nothing but needless issues with custom setups and custom mounts
(which are not uncommon) on /usr/local that are better avoided.
I tried several times to talk Lennart out of that nonsense, but wasn't
successful so far. :)

Post by William Hubbs
TEST_PREFIX UDEVLIBEXECDIR "/rules.d",
+ TEST_PREFIX "/usr/lib/udev/rules.d",
+#ifdef HAVE_SPLIT_USR
+ TEST_PREFIX "/lib/udev/rules.d",
+#endif

I have no problem with that, even when I think it's the wrong way to
do these things. It just creates mess, that is much bigger than the
split-usr ever was. But we have it in systemd, and there is no real
argument for me to make against it.

I'm personally not concerned with /usr/local, but the portion above is
the more important to me. For split /usr systems, there is a lot of
software that installs rules in /lib/udev, so I think we need to support
that directory.

Should I resubmit the patch?

Thanks,

William

[Kay Sievers]

Post by William Hubbs

Post by Kay Sievers

Post by William Hubbs
TEST_PREFIX UDEVLIBEXECDIR "/rules.d",
+ TEST_PREFIX "/usr/lib/udev/rules.d",
+#ifdef HAVE_SPLIT_USR
+ TEST_PREFIX "/lib/udev/rules.d",
+#endif

Now we have 3 instead of one directory here, that really needs to be
sorted out. It's not cool to just add every random thing here. :)

Post by William Hubbs

Post by Kay Sievers
I have no problem with that, even when I think it's the wrong way to
do these things. It just creates mess, that is much bigger than the
split-usr ever was. But we have it in systemd, and there is no real
argument for me to make against it.

I'm personally not concerned with /usr/local, but the portion above is
the more important to me. For split /usr systems, there is a lot of
software that installs rules in /lib/udev, so I think we need to support
that directory.

You are aware that this will not work with the installed binaries in
/lib/udev/ referenced from rules and whatever? The code is really not
made to have this I-read-stuff-from-all-possible locations.

It's a mess you are creating here, by not just merging /lib and
/usr/lib right away.

Post by William Hubbs
Should I resubmit the patch?

Nah, we need to decide what to do first, I'll let you know.

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

[William Hubbs]

Post by Kay Sievers
It's a mess you are creating here, by not just merging /lib and
/usr/lib right away.

I'm not interested in the binaries being installed in /lib/udev. We just
need to be able to read rules from /lib/udev/rules.d along with
/usr/lib/udev/rules.d. The reason is not because of udev, but other
packages which install their rules in /lib/udev/rules.d need to be fixed
to install them in /usr/lib/udev/rules.d.


We are working on fixing things so we can merge /lib into /usr/lib, but
that is a process for us and can't happen over night.

Thanks,

William

[Marco d'Itri]

Post by William Hubbs
/usr/lib/udev/rules.d. The reason is not because of udev, but other
packages which install their rules in /lib/udev/rules.d need to be fixed
to install them in /usr/lib/udev/rules.d.

As the maintainer of udev for a distribution which still supports a
standalone /usr I fail to see how this can be an issue.
Why should an upstream package install something in
/usr/lib/udev/rules.d/ if no distribution supports this directory?

[William Hubbs]

Post by Marco d'Itri

Post by William Hubbs
/usr/lib/udev/rules.d. The reason is not because of udev, but other
packages which install their rules in /lib/udev/rules.d need to be fixed
to install them in /usr/lib/udev/rules.d.

As the maintainer of udev for a distribution which still supports a
standalone /usr I fail to see how this can be an issue.
Why should an upstream package install something in
/usr/lib/udev/rules.d/ if no distribution supports this directory?

I'm not sure if you are asking me or Kay, but here is what we are
running into.

The default configuration of udev-186 installs its rules in
/usr/lib/udev/rules.d. When users upgrade to this udev, they will still
have packages on their system that install rules in /lib/udev/rules.d.
Udev needs to keep this directory as a place for rules for a while for
that reason.

With the /usr merge coming, I'm thinking that packages that install
rules in /lib/udev/rules.d will have to be fixed to install them in
/usr/lib/udev/rules.d eventually, but until then, we should retain
support in udev to read from both places.

Thoughts?

William

[Marco d'Itri]

Post by William Hubbs
With the /usr merge coming, I'm thinking that packages that install
rules in /lib/udev/rules.d will have to be fixed to install them in
/usr/lib/udev/rules.d eventually, but until then, we should retain
support in udev to read from both places.
Thoughts?

Now I see the your point. I need to think a bit about the best
solution for the transition period, but right now I suspect that it
will be a /usr/lib/udev/rules.d/ to /lib/udev/rules.d/ symlink.

(My problem is that I need to think when the symlink should be created
and removed to support the merge, distributions which do not support
upgrades do not need to care about this detail...)

[William Hubbs]

Post by Marco d'Itri

Post by William Hubbs
With the /usr merge coming, I'm thinking that packages that install
rules in /lib/udev/rules.d will have to be fixed to install them in
/usr/lib/udev/rules.d eventually, but until then, we should retain
support in udev to read from both places.
Thoughts?

Now I see the your point. I need to think a bit about the best
solution for the transition period, but right now I suspect that it
will be a /usr/lib/udev/rules.d/ to /lib/udev/rules.d/ symlink.
(My problem is that I need to think when the symlink should be created
and removed to support the merge, distributions which do not support
upgrades do not need to care about this detail...)

I don't follow how a symlink either
/usr/lib/udev/rules.d->/lib/udev/rules.d or the other way around is
going to make the transition work smoothly for us. If we support both
locations as directories, once all of the packages that still install
things in /lib/udev/rules.d give us a way in their upstreams to install
the rules under /usr, /lib/udev/rules.d will just naturally disappear
from everyone's systems.

How is linking /usr/lib/udev/rules.d to /lib/udev/rules.d going to aid
in the transition? That seems to be going backward.

William

[Martin Pitt]

Hello Marco,

Post by Marco d'Itri
Now I see the your point. I need to think a bit about the best
solution for the transition period, but right now I suspect that it
will be a /usr/lib/udev/rules.d/ to /lib/udev/rules.d/ symlink.

FWIW, this seems like the best solution to me. In Debian we don't want
packages (which are under our control) nor third-party packages (which
would be covered by the symlink) to install udev rules (or binaries)
under /usr, as (as far as I understand) Debian still wants to support
a standalone /usr.

I take it the Debian udev/systemd package would not change the layout?
I. e. still install most things under /lib?

Post by Marco d'Itri
(My problem is that I need to think when the symlink should be created
and removed to support the merge

Which merge?

Thanks,

Martin

[Marco d'Itri]

Post by Martin Pitt
I take it the Debian udev/systemd package would not change the layout?
I. e. still install most things under /lib?

Indeed.

Post by Martin Pitt

Post by Marco d'Itri
(My problem is that I need to think when the symlink should be created
and removed to support the merge

Which merge?

The "everything in /usr" merge, which I plan to propose after the
release. Does Ubuntu have plans about this?

[Martin Pitt]

Post by Marco d'Itri

Post by Martin Pitt
Which merge?

The "everything in /usr" merge, which I plan to propose after the
release. Does Ubuntu have plans about this?

No, we don't. We do support a separate /usr (just like Debian), but
quite frankly this is an issue which is of little interest on the
areas Ubuntu is concerned with, so on the the Ubuntu side we won't
spend any work on on this subject, one way or the other. I. e. we'll
continue to support separate /usr for as long as Debian does.

Martin

[William Hubbs]

Post by Marco d'Itri

Post by Martin Pitt
I take it the Debian udev/systemd package would not change the layout?
I. e. still install most things under /lib?

Indeed.

Post by Martin Pitt

Post by Marco d'Itri
(My problem is that I need to think when the symlink should be created
and removed to support the merge

Which merge?

The "everything in /usr" merge, which I plan to propose after the
release. Does Ubuntu have plans about this?

That's the problem with a symlink, either way. How do you know when to
create or remove it?

For us, I would have to do the following on every user's system a udev upgrade:

cp -a /lib/udev /usr/lib/udev
ln -s /usr/lib/udev /lib/udev

Then, I have no idea how I would know when to remove the link.

William

[Kay Sievers]

Post by William Hubbs

Post by Marco d'Itri

Post by Martin Pitt
I take it the Debian udev/systemd package would not change the layout?
I. e. still install most things under /lib?

Indeed.

Post by Martin Pitt

Post by Marco d'Itri
(My problem is that I need to think when the symlink should be created
and removed to support the merge

Which merge?

The "everything in /usr" merge, which I plan to propose after the
release. Does Ubuntu have plans about this?

That's the problem with a symlink, either way. How do you know when to
create or remove it?
cp -a /lib/udev /usr/lib/udev
ln -s /usr/lib/udev /lib/udev
Then, I have no idea how I would know when to remove the link.

Which is why you don't do such a mess.

You keep the historic split as long as it works (some day it will
break step-by-step in non-interesting ways because upstream projects
don't care or test a anymore), or you convert /bin, /sbin, /lib,
/lib64 _one_ go to symlinks.

The conversion of the top-level dirs to symlinks is almost trivial. We
did it in Fedora with no interesting problems at all.
Loading Image...
http://people.freedesktop.org/~kay/usrmove-convert-log.txt

Doing what you try to do here, with creating a total mess with stuff
randomly spread around the filesystem is just plain crazy. We do not
really support that in any tool, and honestly the --enable-split-usr
configure option you added to systemd should just be removed. We do
not support that mess, and it makes no sense to even try. That should
be a distro patch, that makes it clear that you are completely on your
own here.

Better get your stuff together and make decision, by either doing
nothing for now, leaving the stuff in /lib, or by really doing it and
make /lib a symlink. There is no sane option to choose from doing only
a part of it, or gradual, it's just madness.

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

[Marco d'Itri]

Post by William Hubbs
That's the problem with a symlink, either way. How do you know when to
create or remove it?

This is a general problem for every package which ships the same file in
/ and /usr, I fear that the only solution will be to create the link
in postinst if needed.

Post by William Hubbs
The conversion of the top-level dirs to symlinks is almost trivial. We

Except for patching tens of packages which ship the a file with the
same name in / and /usr.

[Kay Sievers]

Post by Marco d'Itri

Post by Kay Sievers
The conversion of the top-level dirs to symlinks is almost trivial. We

Except for patching tens of packages which ship the a file with the
same name in / and /usr.

Which was ~25 for Fedora, which is: nothing.

Then it might be ~75 for Debian, and that can still be fixed in one
single day, if wanted to.

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

[William Hubbs]

Post by Kay Sievers

Post by Marco d'Itri

Post by Kay Sievers
The conversion of the top-level dirs to symlinks is almost trivial. We

Except for patching tens of packages which ship the a file with the
same name in / and /usr.

Which was ~25 for Fedora, which is: nothing.
Then it might be ~75 for Debian, and that can still be fixed in one
single day, if wanted to.

Then there are things like what we did in gentoo years before I came on
board to get around a toolchain bug https://bugs.gentoo.org/4411.

Whoever was working on this back then decided that we should move most
of the critical shared libraries to /lib or /lib64 and put linker
scripts in /usr/lib*. That has to disappear before we can even think
about the /usr merge.

Also, remember that we are a rolling release distro. We do not have
specific gentoo x.x releases; users just go along updating packages. So,
I'm not sure how to force the /usr merge and symlink creation to happen
on all of our users' systems in one go.


William

[William Hubbs]

I need to try to make the issue for us a bit more clear.

Basically gentoo does not have fixed releases, and we support in-place
upgrades of packages. So if udev changes in a way that does not retain
backward compatibility for a while, it will cause breakage for us.

This is why we are asking that you continue supporting rules in
/lib/udev for a while.

Thanks for your consideration,

William

[Lucas De Marchi]

Hi William,

Post by William Hubbs

Post by Kay Sievers

Post by Marco d'Itri

Post by Kay Sievers
The conversion of the top-level dirs to symlinks is almost trivial. We

Except for patching tens of packages which ship the a file with the
same name in / and /usr.

Which was ~25 for Fedora, which is: nothing.
Then it might be ~75 for Debian, and that can still be fixed in one
single day, if wanted to.

Then there are things like what we did in gentoo years before I came on
board to get around a toolchain bug https://bugs.gentoo.org/4411.
Whoever was working on this back then decided that we should move most
of the critical shared libraries to /lib or /lib64 and put linker
scripts in /usr/lib*. That has to disappear before we can even think
about the /usr merge.
Also, remember that we are a rolling release distro. We do not have
specific gentoo x.x releases; users just go along updating packages. So,
I'm not sure how to force the /usr merge and symlink creation to happen
on all of our users' systems in one go.

Talk to Dave and Tom (CC'ed) . Archlinux is a rolling distro as welll,
and they managed to get it working.


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

[Tom Gundersen]

Post by William Hubbs
Whoever was working on this back then decided that we should move most
of the critical shared libraries to /lib or /lib64 and put linker
scripts in /usr/lib*. That has to disappear before we can even think
about the /usr merge.
Also, remember that we are a rolling release distro. We do not have
specific gentoo x.x releases; users just go along updating packages. So,
I'm not sure how to force the /usr merge and symlink creation to happen
on all of our users' systems in one go.

We had a similar issue in Arch. What we did was the following:

Patch udev+kmod+systemd (the last one was for free) to read from
{/usr,}/lib/{modprobe.d,depmod.d,udev/rules.d,systemd/system}.

We then rebuild all the packages that installed binaries to /lib/udev/
and /lib/systemd to move them to their /usr/lib counterparts (as we
did not want to patch udev/systemd to read the helpers from more than
one location).

Then we let people rebuild their packages to move things from /lib to
/usr/lib on a package-by-package basis.

Then we rebuilt all our kernels and pointed kmod/udev to
/usr/lib/modules rather than /lib/modules.

At this point only glibc owned stuff in /lib, so we rebuilt that to
move it all to /usr/lib and replace /lib with a symlink to /usr/lib.

The only step that caused any issues was the last one, and that was
due to users ignoring the upgrade instructions[0] and doing clever
things like "rm -rf /lib".

HTH,

Tom

[0]: <http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by Tom Gundersen
Patch udev+kmod+systemd (the last one was for free) to read from
{/usr,}/lib/{modprobe.d,depmod.d,udev/rules.d,systemd/system}.
We then rebuild all the packages that installed binaries to /lib/udev/
and /lib/systemd to move them to their /usr/lib counterparts (as we
did not want to patch udev/systemd to read the helpers from more than
one location).
Then we let people rebuild their packages to move things from /lib to
/usr/lib on a package-by-package basis.
Then we rebuilt all our kernels and pointed kmod/udev to
/usr/lib/modules rather than /lib/modules.
At this point only glibc owned stuff in /lib, so we rebuilt that to
move it all to /usr/lib and replace /lib with a symlink to /usr/lib.

The problem for us with these steps is that the building happens on
users' systems since we are source based, so we have to go about it
differently. We can't rebuild packages and send them down to the users.

This is why it would be very helpful if udev would keep some backward
compatibility and read rules from /lib/udev/rules.d as long as it was a
directory.

Thanks for consideration,

William

[Greg KH]

Post by William Hubbs

Post by Tom Gundersen
Patch udev+kmod+systemd (the last one was for free) to read from
{/usr,}/lib/{modprobe.d,depmod.d,udev/rules.d,systemd/system}.
We then rebuild all the packages that installed binaries to /lib/udev/
and /lib/systemd to move them to their /usr/lib counterparts (as we
did not want to patch udev/systemd to read the helpers from more than
one location).
Then we let people rebuild their packages to move things from /lib to
/usr/lib on a package-by-package basis.
Then we rebuilt all our kernels and pointed kmod/udev to
/usr/lib/modules rather than /lib/modules.
At this point only glibc owned stuff in /lib, so we rebuilt that to
move it all to /usr/lib and replace /lib with a symlink to /usr/lib.

The problem for us with these steps is that the building happens on
users' systems since we are source based, so we have to go about it
differently. We can't rebuild packages and send them down to the users.

No, but we can fix all packages in the tree, and then update the udev
version, with a big fat warning / error when we install the new udev
package saying that the rules need to be fixed by updating the packages
that placed them there.

Post by William Hubbs
This is why it would be very helpful if udev would keep some backward
compatibility and read rules from /lib/udev/rules.d as long as it was a
directory.

I don't think this is really necessary, as long as we just fix up all
packages in the tree that are doing things wrong. That shouldn't take
very long (hint, if you need help, I'll be glad to do so.)

thanks,

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

[William Hubbs]

Post by Greg KH

Post by William Hubbs

Post by Tom Gundersen
Patch udev+kmod+systemd (the last one was for free) to read from
{/usr,}/lib/{modprobe.d,depmod.d,udev/rules.d,systemd/system}.
We then rebuild all the packages that installed binaries to /lib/udev/
and /lib/systemd to move them to their /usr/lib counterparts (as we
did not want to patch udev/systemd to read the helpers from more than
one location).
Then we let people rebuild their packages to move things from /lib to
/usr/lib on a package-by-package basis.
Then we rebuilt all our kernels and pointed kmod/udev to
/usr/lib/modules rather than /lib/modules.
At this point only glibc owned stuff in /lib, so we rebuilt that to
move it all to /usr/lib and replace /lib with a symlink to /usr/lib.

The problem for us with these steps is that the building happens on
users' systems since we are source based, so we have to go about it
differently. We can't rebuild packages and send them down to the users.

No, but we can fix all packages in the tree, and then update the udev
version, with a big fat warning / error when we install the new udev
package saying that the rules need to be fixed by updating the packages
that placed them there.

Post by William Hubbs
This is why it would be very helpful if udev would keep some backward
compatibility and read rules from /lib/udev/rules.d as long as it was a
directory.

I don't think this is really necessary, as long as we just fix up all
packages in the tree that are doing things wrong. That shouldn't take
very long (hint, if you need help, I'll be glad to do so.)

Hey greg,

write to me off list and let me know what we need to do and we can go
from there.

Thanks,

William