Re: [ANNOUNCE] udev 125 release

[Doug Goldstein <cardoe@gentoo.org>]

Kay Sievers wrote:
> 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
>
>   
I mentioned in my first e-mail that there is a symlink from /lib/udev 
already. So once again, there is no brokenness.