Re: [ANNOUNCE] udev 125 release

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, 2008-07-21 at 20:06 -0400, David Zeuthen wrote:
> (Resent, this time with the correct address for linux-hotplug)
> 
> On Mon, 2008-07-21 at 16:56 -0400, Doug Goldstein wrote:
> > Firstly, there's an inherit symlink that occurs anyway so there is no 
> > ABI breakage. And secondly, Kay has clearly stated that these are 
> > private rules for udev and udev alone.

No, I stated that rules which are not supposed to be edited should move
to /lib/udev/rules.d/, including the stuff from all the other packages.

> They ship with udev and are replaced only by udev. 

The udev owned rules are only replaced by udev, sure. But other packages
use that too. /etc/udev/rules.d/ should be only for on-demand, or user
created rules. Just think of a fully converted system, where you could
do "rm /etc/udev/rules.d/*" if you want to start from scratch.

> Hardly. Kay said
> 
> > but we suggest to move things which are not supposed to be changed
> > by users/admins to the private rules directory.
> 
> Now please explain why on earth 3rd party packages would use the
> directory /etc/udev/rules.d instead of /lib/udev/rules.d? If they did
> they would suffer from exactly the same problems as Kay is trying to
> solve for udev. It just doesn't make sense to consider /lib/udev an
> implementation detail only. There in lies madness.
> 
> > If any package uses them in anyway other then 
> > through proper udev mechanisms, that package is broken and relying on
> an 
> > unstable "ABI". If you can even consider files which are private to a 
> > package which shouldn't be edited to be an Application Binary 
> > Interface... 

They are "private to a package" in a sense that the user/admin has not
to touch it, and they get replaced on package update without any
warning.

> It seems like you thought I wrote "/lib/udev/rules.d" instead of
> "/lib/udev". Please read my mail again. FWIW, some packages on my Fedora
> system (bluez-utils, initscripts among others) already put stuff
> in /lib/udev and I bet it's similar on most distros.

Sure, we have lots of packages doing that, and it is the right thing to
do.

> > I believe that was a bit of a stretch to use those terms.
> 
> Not at all. But I don't really want to discuss this with you. Let's
> instead just query Kay about whether it's fine to consider /lib/udev as
> an ABI, e.g. in particular whether it's fine for 3rd party packages to
> drop files in /lib/udev and /lib/udev/rules.d. Kay?

Absolutely, /lib/udev/ _is_ a public interface, and the only place
supported by udev. /lib64/udev/ is a broken installation. The source
code even hard-codes that path in some cases. It is intentionally not
configurable.

LSB suggests directories like this, it is well defined, that part of LSB
makes a lot of sense, and we use it that way.

3rd parties use it, and do not need to care where they will find it,
every properly installed system has it at /lib/udev/.

/lib64/ is for libraries, we do not ship any, and if we do, we sure will
put them in /lib64/, and not in /lib/udev/. But still, only the libs,
not any other files. As long as people do not have /sbin64/ and such,
the whole discussion about multi-arch for non-libraries is completely
superfluous anyway.

Matthias, Doug, it would be nice, if you can fix the udev package on
Gentoo, it is broken to use /lib64/udev/.

Btw, where are your kernel modules? In /lib64/modules/?

Thanks,
Kay