From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Date: Tue, 22 Jul 2008 13:15:17 +0000 Subject: Re: [ANNOUNCE] udev 125 release Message-Id: <4885DD65.50405@gentoo.org> List-Id: References: <1216627334.7816.12.camel@linux.site> In-Reply-To: <1216627334.7816.12.camel@linux.site> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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.