All,
I am about to release udev-186-r1, which will move everything currently
in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an eclass
that tests the version of udev installed on the user's system and
installs the udev rules in the proper place. I'm not sure how many
packages do this, so if it is a very small number of packages, it may
not be worth the eclass. It would be good to discuss that as well as
reviewing the proposed eclass.
Thanks,
William
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v 1.11 2012/01/07 17:53:47 mgorny Exp $
# @ECLASS: udev-rules.eclass
# @MAINTAINER:
# udev-bugs@gentoo.org
# @BLURB: helper functions to install udev rules
# @DESCRIPTION:
# This eclass provides a set of functions to install udev rules.
# With versions of udev prior to 186, udev rules for extra packages were
# installed in /lib/udev/rules.d, but with newer versions they are installed in
# /usr/lib/udev/rules.d.
# @EXAMPLE:
#
# @CODE
# inherit udev-rules
#
# src_install() {
# udev_dorules "${FILESDIR}"/foo.rules "${FILESDIR}"/bar.rules
# udev_newrules "${FILESDIR}"/old.rules.name baz.rules
# }
# @CODE
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
# @FUNCTION: _udev_get_rulesdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
if has_version '<sys-fs/udev-186-r1'; then
dir=/lib/udev/rules.d
else
dir=/usr/lib/udev/rules.d
fi
echo -n $dir
}
# @FUNCTION: udev_get_rulesdir
# @DESCRIPTION:
# Output the path for the udev rules directory (not including ${D}).
udev_get_rulesdir() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
debug-print-function ${FUNCNAME} "${@}"
echo -n "${EPREFIX}$(_udev_get_rulesdir)"
}
# @FUNCTION: udev_dorules
# @USAGE: rulesfile [...]
# @DESCRIPTION:
# Install udev rule(s). Uses doins, thus it is fatal in EAPI 4
# and non-fatal in earlier EAPIs.
udev_dorules() {
debug-print-function ${FUNCNAME} "${@}"
# @FUNCTION: udev_newrules
# @USAGE: oldname newname
# @DESCRIPTION:
# Install udev rules file with a new name. Uses newins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
udev_newrules() {
debug-print-function ${FUNCNAME} "${@}"
On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass.
I do this in sci-misc/comedi-headers (wtk overlay). Actually, I had
just been installing the rules into /etc/udev/rules.d, because I
hadn't read the docs thoroughly enough. +1 for an eclass to handle
this for me .
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
07-11-2012, 08:57 PM
Diego Elio Pettenò
rfc: udev-rules.eclass
Il 11/07/2012 21:11, William Hubbs ha scritto:
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
Unless you're going to establish a symlink, please keep it under p.mask
until everything is using some common code — otherwise things _will_ break.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
07-11-2012, 08:57 PM
William Hubbs
rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
If there are no objections, I will commit this to the tree, no earlier
than 15 July UTC.
Thanks,
William
07-11-2012, 08:59 PM
Alexis Ballier
rfc: udev-rules.eclass
On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs <williamh@gentoo.org> wrote:
> All,
> I am about to release udev-186-r1, which will move everything
> currently in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
How do you plan to handle the following:
- foo installs an udev rule
- install foo with old udev
- upgrade udev
are rules installed by foo used by new udev ?
A.
07-11-2012, 09:51 PM
"Rick "Zero_Chaos" Farina"
rfc: udev-rules.eclass
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/11/2012 03:11 PM, William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
>
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.
I have at least half a dozen ebuilds which install rules (if you include
gentoo-x86 and pentoo overlay)
I'm guessing an eclass would be a good idea.
Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
> Il 11/07/2012 21:11, William Hubbs ha scritto:
> > I am about to release udev-186-r1, which will move everything currently
> > in /lib/udev to /usr/lib/udev.
>
> Unless you're going to establish a symlink, please keep it under p.mask
> until everything is using some common code — otherwise things _will_ break.
Since multiple packages put things in /lib/udev, I'm not sure it is
possible to establish a symlink from /lib/udev to /usr/lib/udev if
that's what you mean; I'll look into it though.
My concern about p.mask is things tend to die there. How will we know
for sure when there will not be any breakages without putting it in
~arch to see what breaks?
William
07-11-2012, 11:43 PM
Diego Elio Pettenò
rfc: udev-rules.eclass
Tinderbox will help you there.
On Thursday, July 12, 2012, William Hubbs wrote:
On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
> Il 11/07/2012 21:11, William Hubbs ha scritto:
> > I am about to release udev-186-r1, which will move everything currently
> > in /lib/udev to /usr/lib/udev.
>
> Unless you're going to establish a symlink, please keep it under p.mask
> until everything is using some common code — otherwise things _will_ break.
Since multiple packages put things in /lib/udev, I'm not sure it is
possible to establish a symlink from /lib/udev to /usr/lib/udev if
that's what you mean; I'll look into it though.
My concern about p.mask is things tend to die there. How will we know
for sure when there will not be any breakages without putting it in
~arch to see what breaks?
William
07-11-2012, 11:48 PM
William Hubbs
rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
> How do you plan to handle the following:
> - foo installs an udev rule
> - install foo with old udev
> - upgrade udev
>
> are rules installed by foo used by new udev ?
No, they wouldn't be; that is a good reason to question the value of the
eclass itself. Maybe the correct way to do this is to forget the eclass
and just file bugs against packages that break having them move their
rules to the new location and set a dependency on the newer udev.
This would have to be a rev bump for the broken packages.
William
>
> A.
>
07-12-2012, 02:25 AM
"Rick "Zero_Chaos" Farina"
rfc: udev-rules.eclass
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/11/2012 07:48 PM, William Hubbs wrote:
> On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
>> How do you plan to handle the following:
>> - foo installs an udev rule
>> - install foo with old udev
>> - upgrade udev
>>
>> are rules installed by foo used by new udev ?
>
> No, they wouldn't be; that is a good reason to question the value of the
> eclass itself. Maybe the correct way to do this is to forget the eclass
> and just file bugs against packages that break having them move their
> rules to the new location and set a dependency on the newer udev.
Perhaps a new ebuild helper would be best here? It seems no one knows
where to install udev rules in the first place (I know I didn't till a
recent version of portage yelled at me with a QA warning).
How about dorule/newrule?
- -Zero
>
> This would have to be a rev bump for the broken packages.
>
> William
>
>>
>> A.
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
rfc: udev-rules.eclass
.
