[gentoo-dev] rfc: udev-rules.eclass

[gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 502 bytes --]

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


[-- Attachment #1.2: udev-rules.eclass --]
[-- Type: text/plain, Size: 2010 bytes --]

# 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} "${@}"

	(
		insinto "$(_udev_get_rulesdir)"
		doins "${@}"
	)
}

# @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} "${@}"

	(
		insinto "$(_udev_get_rulesdir)"
		newins "${@}"
	)
}

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

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/




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Alexis Ballier]

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.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Rick "Zero_Chaos" Farina]

-----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/

iQIcBAEBAgAGBQJP/fVvAAoJEKXdFCfdEflKQcQP/igsYucmoFmJuozob2vFyKhw
iTs/T3zFqyJXZh4k4WygQUhbrPToNkIvs24Ic7Zb90lYDlva1W24Vj4r+GBMOEEF
19q3wk3SDnZZI6ulLlpx6jTh4uzJeTl8jO3efOpHcnbXKjf3pJJGldotkYmbz1pD
ALrZywqYCpDAf2ioQFKafBnpY7coe/qyzgtOScGy680V+YIFSX0mmHl0MAFJ/jyH
V4gQvzsag227FILTRdmqMm/megYFY9POplRTVPeu/1vn6oGabPk6d+OmwR+uGoYL
8EpdG1W4RMsXGYBUsbFZWPO+q/MfJaZXa5DmwHc7z/MgNIYCj3cYmX750sWBW1EJ
GclSnu0/ykJ4I3ABMXyK3d9ZEPbjXrrEY09YVTkxd3Un1zA3LEjRSP3VBu74xvUN
oMf7MPxYuMK8ynR705j4r/WCZINKQhBRwNxUXnVrqsD0HS0qJRhZ4iYI3WzrJv7g
rGO+K8IgZLzXaWQXSocbtAlJcl1juf47O1qu2PhtNbopC+G+s1s/A3wZwjNY3LHl
Zj3nwzsijumsKid4TvHzlGtL28yPy5fQU+hniCapFr0M9QChBhLEH4VxTGqX4MzP
YEVwBEqq/QZD9T8b0Hdw7PW8KTJCX7ttemW5x27WRHHSoYP2qwoOoycixuUNpJ0j
XLt/mIBoiAiRJUHkynN4
=1aWY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 1097 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

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.
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Rick "Zero_Chaos" Farina]

-----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/

iQIcBAEBAgAGBQJP/jWIAAoJEKXdFCfdEflKwPUP/25MRtz2WYr/ajnGIFks7Rge
KFlCkIVILejW/5Bh2Ct+OUhcIcT26lENIyRi+agXxvmI6eO5RwWFz1uqinM10dc5
eQ2rdq+SzM5yrRDuy3aQRNSpemGPIT9Rnmz+/JwgqaeEbl5qMLglqIjZcU9sL675
bfFF0n6y2/HuSFY1kZ6elK5A4UBnM3LRVl6DYZlYPH0/KzSYo03qQlgrUKzODaZ6
C+d1Ctd1g8yCuMmrk2QvAuPO1dxNJHV6zWIQFmuVOZrDKxoQyiS73HwG53oeqwN1
Ig1tZo9X8co4gb8f6YcxxG6tAligqMXRbBCHwdZh1JEeLfAtA6hFxmVZ4u+Ldj9W
Eco1MAGSX3qoUfoEJQeI49AcjMIkIBHR7kyvl7/IJ10xjI1QWsa9Cx2kkowaGbCw
CuNlqmMLsAyOVDXdAoW/ODC/2ntNsnigv8J5m6kJ2sUzzGVzU2q1VBxkTfLQkkD4
1H0nReTSo3ilNN9ZpsBEer+xMz1xsXssDbkQGXxRi0modKYUe2z9JZ0bJweFDn2I
ixEooL6D67TFS3lhkScGA0S4WO1lUO+Ih1cb6SPvGOpx+R6A+o1IYWC3utdIB1ho
mGDyK8NB9fNgP3B5PAjACWPoTSs4IMRIiLBMfCIperbPNrAFGrzwJcbLnxaNy7KY
l5ug3XKuM/B2yZdxyzSu
=8j1W
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Zac Medico]

On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote:
> 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?

I guess then we'd need the installed udev to set an environment variable
via /etc/env.d, in order to control the location where the rules are
installed?
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: udev-rules.eclass

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 10:50 PM, Zac Medico wrote:
> On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote:
>> 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?
> 
> I guess then we'd need the installed udev to set an environment variable
> via /etc/env.d, in order to control the location where the rules are
> installed?

Oh I'm sorry, I didn't mean to sound like I had an actual implementation
idea in my head :-)  I yield to those with greater experience on that,
but yeah, env makes some sense to me.

Thanks
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP/j6aAAoJEKXdFCfdEflKyJMQAJZIm4YNbmYl7EjFCU4JaNjg
PJAwz1kSCCmhiQYw60FHEvdZdC4cR5v/VhBpHW0Im53yTRE6vgwjrFybze0YG9u7
UYNbz6jAZ5HYSj5CCxxCwSMricREBJcnRqZU8til8M3ayw4jI7IpRQJYOdjd923T
M2b7YFW64JrGXZtpUR2Uc9KMDdgAVoMmIp5JmERTYiJxqu8RhdAWBD8Ey8xsQQIX
+mT+rkoIRc5VSEnsJues59TecSDdEgYYdYGwDv81euMBTYbEbuNolImav8L2AxJZ
8k4jXPF8oVn73ehmLKjenkeiYJHVBiPycG53Q95f7Hs/YavXChtcrOg6MLsdhfTn
tqrClTvOu3rvaboIfGF+QXWpi+kH0ltlPLNIyH0Q0bPCnHmwAtb43NqqprFo77/v
pMkjOzRZ5rf6p+SnCE6ouwZMJS4FYSWsGKIoRwBgQm6eCj9RXNV59lFe0zW2pi9b
Qf/AwR16ZeNWQovHCxYmUupGwLtEbB12sDP9hSnq+FcHAMbwvcyZamxibo9DPY+K
eNc9kn7cvHu+Z3B1O3O1yfIKwYsTeVkZUMw1Sn1Y3SwtwXBNnWc/8YM41pdjSfpK
bydnt8FTUeLUhLtIYzUtsN9s99S3u2rhfkPUWapeNdYYCOCMrxMl3tx52rNFggwT
w03B9r0mUngc5DBzaUg6
=sg7B
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Wed, 2012-07-11 at 18:48 -0500, 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.
> 
> This would have to be a rev bump for the broken packages.
> 
> William
> 
> > 
> > A.
> > 

So, does that mean the rule itself changes or just the location change
is needed?

If it is just a location change, a fairly simple udev-updater script
would do it.  If the pkg needs to be re-compiled to work with/depend on
the new udev, then a more complex script would be needed.  One more
along the line of python-updater/perl-cleaner.
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ben de Groot]

On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.

Couldn't you, on udev upgrade, move everything in /lib/udev to
/usr/lib/udev, and then make the symlink? Seems fairly simple
to me, but maybe I'm overlooking something?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] rfc: udev-rules.eclass

[Zac Medico]

On 07/11/2012 10:01 PM, Ben de Groot wrote:
> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.
> 
> Couldn't you, on udev upgrade, move everything in /lib/udev to
> /usr/lib/udev, and then make the symlink? Seems fairly simple
> to me, but maybe I'm overlooking something?
> 

It seems like that would work well. :)
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

On Thu, 12 Jul 2012 13:01:21 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.
> 
> Couldn't you, on udev upgrade, move everything in /lib/udev to
> /usr/lib/udev, and then make the symlink? Seems fairly simple
> to me, but maybe I'm overlooking something?

You are overlooking conflicts introduced through moving files without
updating vardb.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Zac Medico]

On 07/12/2012 12:17 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 13:01:21 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> 
>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.
>>
>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>> /usr/lib/udev, and then make the symlink? Seems fairly simple
>> to me, but maybe I'm overlooking something?
> 
> You are overlooking conflicts introduced through moving files without
> updating vardb.
> 

Maybe that's package manager dependent. I think it should work fine with
Portage though.
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/07/12 01:01 AM, Ben de Groot wrote:
> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.
> 
> Couldn't you, on udev upgrade, move everything in /lib/udev to 
> /usr/lib/udev, and then make the symlink? Seems fairly simple to
> me, but maybe I'm overlooking something?
> 

A symlink isn't a good idea as, iirc, the new udev still -reads- from
both /usr/lib/udev and /lib/udev ..  so it'd have two sources for the
exact same rules; could be an issue.

Given this, the way I see it all we need is a helper s.t. all installs
going forward put the rules into the right place according to the
installed udev (or maybe the installed virtual/device-manager) so that
ebuilds/packages dont need to worry about setting the paths
explicitly; and eventually as things progress all the rules in
/lib/udev will get cleaned out in favour of /usr/lib/udev ...  ?

We could always just forgo the helper and make all packages migrate
via a >=udev-186-r1 dep and setting the rules install paths explicitly
to /usr/lib/udev ...  the helper (to me) just makes this cleaner in
the ebuild..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1J0ACgkQ2ugaI38ACPAaRgEAuknxIx3LOgVniVsEqxrwWfnj
vNW5Zc/6/ZCn8QL+LZ8A/iepdgiZ7bmYtUb+Zj537o46z/prXP290q6oo/2DQy2j
=G32M
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/07/12 03:17 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot <yngwin@gentoo.org>
> wrote:
> 
>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
>> 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.
>> 
>> Couldn't you, on udev upgrade, move everything in /lib/udev to 
>> /usr/lib/udev, and then make the symlink? Seems fairly simple to
>> me, but maybe I'm overlooking something?
> 
> You are overlooking conflicts introduced through moving files
> without updating vardb.
> 

There were no vdb issues when baselayout-1 was migrated to
baselayout-2, and it rewrote a whackload of stuff iirc...

Updating vdb shouldn't be an issue here, as long as pkg_postinst
doesn't crash mid-stream.  Is the vdb common between package managers
or does each one have a different solution?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1XUACgkQ2ugaI38ACPBKdgD/S3jlct63PVIKE8UmHW4jEanZ
T2/lgnF/cUzTSlsyrEQA/iQWSvOcowsgI/r2VUlJLFpltNVea/f8pm5wKq5F4cjk
=HA5O
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On Thu, 12 Jul 2012 09:47:33 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/07/12 03:17 AM, Michał Górny wrote:
> > On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot <yngwin@gentoo.org>
> > wrote:
> > 
> >> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
> >> 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.
> >> 
> >> Couldn't you, on udev upgrade, move everything in /lib/udev to 
> >> /usr/lib/udev, and then make the symlink? Seems fairly simple to
> >> me, but maybe I'm overlooking something?
> > 
> > You are overlooking conflicts introduced through moving files
> > without updating vardb.
> > 
> 
> There were no vdb issues when baselayout-1 was migrated to
> baselayout-2, and it rewrote a whackload of stuff iirc...
> 
> Updating vdb shouldn't be an issue here, as long as pkg_postinst
> doesn't crash mid-stream.  Is the vdb common between package managers
> or does each one have a different solution?

Yes, it is common because for many years people keep noticing it is
common and using that. In other words, for many there is a failing
attempt to stop relying on its format.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Thu, 12 Jul 2012 09:43:57 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/07/12 01:01 AM, Ben de Groot wrote:
> > On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org> 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.
> > 
> > Couldn't you, on udev upgrade, move everything in /lib/udev to 
> > /usr/lib/udev, and then make the symlink? Seems fairly simple to
> > me, but maybe I'm overlooking something?
> > 
> 
> A symlink isn't a good idea as, iirc, the new udev still -reads- from
> both /usr/lib/udev and /lib/udev ..

Does it? I wasn't able to reproduce and wanted to start convincing Kay
to let it do that...


-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs <williamh@gentoo.org> wrote:

> # @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
> }

For now, I think it would be better to just use /lib/udev/rules.d. We
can decide on moving the rules later.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/07/12 10:19 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 09:47:33 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> Updating vdb shouldn't be an issue here, as long as pkg_postinst 
>> doesn't crash mid-stream.  Is the vdb common between package
>> managers or does each one have a different solution?
> 
> Yes, it is common because for many years people keep noticing it
> is common and using that. In other words, for many there is a
> failing attempt to stop relying on its format.
> 

..i'm not following this -- so it's common (ie, portage, paludis, etc
all use it) because it's always been there?

Anyways, if all the package managers do use it, then there isn't any
reason at this juncture to not handle this via an update to vdb.  If
in the future different package managers use something different, then
we'd need to have individual vdb-update scripts for each (differing)
pms, but unless I misread you this is currently a non-issue..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+4GQACgkQ2ugaI38ACPDP8QD9HPv+l8vFW7cm/xA5ksKhUUyD
xzOtVY93XLL3ArhqlYkBAJxi98IIk5qWib6BK7VckhQLwJVmmHO+xtDPFuhP78rU
=YIIr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/07/12 10:20 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 12/07/12 01:01 AM, Ben de Groot wrote:
>>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
>>> 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.
>>> 
>>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>>>  /usr/lib/udev, and then make the symlink? Seems fairly simple
>>> to me, but maybe I'm overlooking something?
>>> 
>> 
>> A symlink isn't a good idea as, iirc, the new udev still -reads-
>> from both /usr/lib/udev and /lib/udev ..
> 
> Does it? I wasn't able to reproduce and wanted to start convincing
> Kay to let it do that...
> 
> 

..i was going by your statement, i guess i misread you (thought you
said that it did, not that it should)..  Sorry!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+4JAACgkQ2ugaI38ACPCJSgEAp8xI9d8dDO5G2l1lC/pYGT+c
P1rx1XWffLntT12AG94A/j2321qa6OeC+I8AXmK2N+CtWt1FMSzP250H7yMkB0CH
=MERT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Thu, Jul 12, 2012 at 04:22:20PM +0200, Michał Górny wrote:
> On Wed, 11 Jul 2012 14:11:42 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > # @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
> > }
> 
> For now, I think it would be better to just use /lib/udev/rules.d. We
> can decide on moving the rules later.

We can hold off on this for udev-186. Sometime soon though we will need
to move the rools.

The more I think about it it will do best to be a hard dependency on
>=sys-fs/udev-187 and not worry about the whole eclass issue.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 12 Jul 2012 10:34:12 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> ..i'm not following this -- so it's common (ie, portage, paludis, etc
> all use it) because it's always been there?

It's sort of commonish because there's some disgusting code in some
eclasses that sort of relies upon its format being sort of right. We
have yet to manage to do away with that code, which is annoying,
because VDB's format stinks.

- -- 
Ciaran McCreesh

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk/+4T0ACgkQ96zL6DUtXhEXYACfaxKsxed/K0QIKSVKXry/Zkkv
sKEAn14ssmyzDzmdT9oMeodQvRMfRHis
=VFuE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Thu, 12 Jul 2012 10:34:56 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 12/07/12 10:20 AM, Michał Górny wrote:
> > On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> On 12/07/12 01:01 AM, Ben de Groot wrote:
> >>> On 12 July 2012 07:42, William Hubbs <williamh@gentoo.org>
> >>> 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.
> >>> 
> >>> Couldn't you, on udev upgrade, move everything in /lib/udev to
> >>>  /usr/lib/udev, and then make the symlink? Seems fairly simple
> >>> to me, but maybe I'm overlooking something?
> >>> 
> >> 
> >> A symlink isn't a good idea as, iirc, the new udev still -reads-
> >> from both /usr/lib/udev and /lib/udev ..
> > 
> > Does it? I wasn't able to reproduce and wanted to start convincing
> > Kay to let it do that...
> > 
> > 
> 
> ..i was going by your statement, i guess i misread you (thought you
> said that it did, not that it should)..  Sorry!

I will try to convince upstream to support it that way.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Alexis Ballier]

On Wed, 11 Jul 2012 18:48:08 -0500
William Hubbs <williamh@gentoo.org> 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.
> 
> This would have to be a rev bump for the broken packages.

this sounds heavy for only changing the location of a file, but that's
the only sane solution i can think of :(

A.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Alexis Ballier]

On Wed, 11 Jul 2012 20:41:04 -0700
Brian Dolbec <dolsen@gentoo.org> wrote:

> On Wed, 2012-07-11 at 18:48 -0500, 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.
> > 
> > This would have to be a rev bump for the broken packages.
> > 
> > William
> > 
> > > 
> > > A.
> > > 
> 
> So, does that mean the rule itself changes or just the location change
> is needed?
> 
> If it is just a location change, a fairly simple udev-updater script
> would do it. 
[...]

how do you handle the package manager database containing the location
of the file ?

A.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Alexis Ballier]

On Wed, 11 Jul 2012 19:50:42 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 07/11/2012 07:25 PM, Rick "Zero_Chaos" Farina wrote:
> > 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?
> 
> I guess then we'd need the installed udev to set an environment
> variable via /etc/env.d, in order to control the location where the
> rules are installed?

Having the location of installed files depend on environment variables
always sounded bad practices to me. Maybe it is quite common, but I
remember specifically hardcoding paths in TeXLive's ebuilds/eclasses to
avoid this behavior.

A.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Samuli Suominen]

On 07/11/2012 10: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.
>
> Thanks,
>
> William
>

Please don't hardcode the path like this, use pkg-config instead:

inherit toolchain-funcs

dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"

Re: [gentoo-dev] rfc: udev-rules.eclass

[Mike Gilbert]

On Thu, Jul 12, 2012 at 3:58 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Please don't hardcode the path like this, use pkg-config instead:
>
> inherit toolchain-funcs
>
> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>

Heh, I didn't realize udev installed a pkg-config file for that. Nice.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On 07/13/2012 12:04 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 22:58:29 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 07/11/2012 10: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.
>>>
>>> Thanks,
>>>
>>> William
>>>
>>
>> Please don't hardcode the path like this, use pkg-config instead:
>>
>> inherit toolchain-funcs
>>
>> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>
> Don't forget to add udev to DEPEND of every package using the eclass
> then. Oh wait...
>

Obviously the pkg-config should be only the primary method and there 
should be a fallback, like what has already been posted.

See attachment.




[-- Attachment #2: udev-rules.eclass.patch --]
[-- Type: text/x-patch, Size: 733 bytes --]

--- udev-rules.eclass.orig	2012-07-12 23:59:40.465838370 +0300
+++ udev-rules.eclass	2012-07-13 00:01:12.921831177 +0300
@@ -22,6 +22,8 @@
 # }
 # @CODE
 
+inherit toolchain-funcs
+
 case ${EAPI:-0} in
 	0|1|2|3|4) ;;
 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
@@ -33,10 +35,14 @@
 # Get unprefixed udev rules directory.
 _udev_get_rulesdir() {
 	local dir
-	if has_version '<sys-fs/udev-186-r1'; then
-		dir=/lib/udev/rules.d
+	if has_version virtual/pkgconfig; then
+		dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
 	else
-		dir=/usr/lib/udev/rules.d
+		if has_version '<sys-fs/udev-186-r1'; then
+			dir=/lib/udev/rules.d
+		else
+			dir=/usr/lib/udev/rules.d
+		fi
 	fi
 	echo -n $dir
 }

Re: [gentoo-dev] rfc: udev-rules.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 07/11/2012 10: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.
> >
> > Thanks,
> >
> > William
> >
> 
> Please don't hardcode the path like this, use pkg-config instead:
> 
> inherit toolchain-funcs
> 
> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"

Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: udev-rules.eclass

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

On 07/13/2012 12:01 AM, Samuli Suominen wrote:
> On 07/13/2012 12:04 AM, Michał Górny wrote:
>> On Thu, 12 Jul 2012 22:58:29 +0300
>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>
>>> On 07/11/2012 10: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.
>>>>
>>>> Thanks,
>>>>
>>>> William
>>>>
>>>
>>> Please don't hardcode the path like this, use pkg-config instead:
>>>
>>> inherit toolchain-funcs
>>>
>>> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>>
>> Don't forget to add udev to DEPEND of every package using the eclass
>> then. Oh wait...
>>
>
> Obviously the pkg-config should be only the primary method and there
> should be a fallback, like what has already been posted.
>
> See attachment.

Err, this one.

[-- Attachment #2: udev-rules.eclass.patch --]
[-- Type: text/x-patch, Size: 742 bytes --]

--- udev-rules.eclass.orig	2012-07-12 23:59:40.465838370 +0300
+++ udev-rules.eclass	2012-07-13 00:09:00.138793712 +0300
@@ -22,6 +22,8 @@
 # }
 # @CODE
 
+inherit toolchain-funcs
+
 case ${EAPI:-0} in
 	0|1|2|3|4) ;;
 	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
@@ -33,10 +35,14 @@
 # Get unprefixed udev rules directory.
 _udev_get_rulesdir() {
 	local dir
-	if has_version '<sys-fs/udev-186-r1'; then
-		dir=/lib/udev/rules.d
+	if "$($(tc-getPKG_CONFIG) --exists udev)"; then
+		dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
 	else
-		dir=/usr/lib/udev/rules.d
+		if has_version '<sys-fs/udev-186-r1'; then
+			dir=/lib/udev/rules.d
+		else
+			dir=/usr/lib/udev/rules.d
+		fi
 	fi
 	echo -n $dir
 }

[gentoo-dev] Re: rfc: udev-rules.eclass

[Jonathan Callen]

On 07/12/2012 05:09 PM, Samuli Suominen wrote:
> @@ -33,10 +35,14 @@
>  # Get unprefixed udev rules directory.
>  _udev_get_rulesdir() {
>  	local dir
> -	if has_version '<sys-fs/udev-186-r1'; then
> -		dir=/lib/udev/rules.d
> +	if "$($(tc-getPKG_CONFIG) --exists udev)"; then

This should probably be:

    if $(tc-getPKG_CONFIG) --exists udev 2>/dev/null; then

> +		dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>  	else
> -		dir=/usr/lib/udev/rules.d
> +		if has_version '<sys-fs/udev-186-r1'; then
> +			dir=/lib/udev/rules.d
> +		else
> +			dir=/usr/lib/udev/rules.d
> +		fi
>  	fi
>  	echo -n $dir
>  }

-- 
Jonathan Callen

Re: [gentoo-dev] rfc: udev-rules.eclass

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

On Thu, 2012-07-12 at 12:30 -0400, Alexis Ballier wrote:
> On Wed, 11 Jul 2012 20:41:04 -0700
> Brian Dolbec <dolsen@gentoo.org> wrote:
> 
> > On Wed, 2012-07-11 at 18:48 -0500, 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.
> > > 
> > > This would have to be a rev bump for the broken packages.
> > > 
> > > William
> > > 
> > > > 
> > > > A.
> > > > 
> > 
> > So, does that mean the rule itself changes or just the location change
> > is needed?
> > 
> > If it is just a location change, a fairly simple udev-updater script
> > would do it. 
> [...]
> 
> how do you handle the package manager database containing the location
> of the file ?
> 
> A.
> 

Personally, since I'm not a bash programmer, I'd use python.  And since
this is the package managers db, I'd use the pkg manager to do it.
Specifically I'd create an emaint module to do it in the fully
modular/plug-in-able emaint rewrite I did (waiting for Zac's review,
merge). It can make it's modules fully available for direct or managed
import by other portage code, or other scripts. In fact in that branch I
moved some clean-logs code from emerge into an emaint module, extended
it a bit so you can change the time setting, run pretend runs (-c,
--check)... and had the emerge FEATURE run it instead.  So you could run
it independently of emerge if you choose.

There is an outdated vdbkeys emaint module that did changes and updates
to several files in a pkg's vdb directory.  Creating one to do this
should be quite simple. 

That said, I don't profess to know what other possible ramifications
there would be to changing a few entries in a pkg's CONTENTS file.  I'll
leave that up to Zac and the others. But I haven't heard any screaming
of breakage that would occur for doing so. 
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: rfc: udev-rules.eclass

[Duncan]

Zac Medico posted on Thu, 12 Jul 2012 00:33:50 -0700 as excerpted:

>>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>>> /usr/lib/udev, and then make the symlink? Seems fairly simple to me,
>>> but maybe I'm overlooking something?
>> 
>> You are overlooking conflicts introduced through moving files without
>> updating vardb.
>> 
>> 
> Maybe that's package manager dependent. I think it should work fine with
> Portage though.

Confirmed.  This is the way amd64 has handled the lib -> lib64 symlink 
(sometimes reversed) for years (which is why the whole FEATURES=multilib-
strict thing was needed to try and keep things straight).  As long as the 
symlink is there, portage will follow the symlink and manage the files 
just fine.

FWIW, a similar trick was used when migrating X-related stuff from 
/usr/X11R6/ to simply /usr/ .  The files were moved up a level into /usr, 
and /usr/X11R6 became a symlink -> . , thus pointing back to /usr/ .   
IIRC, existing package versions still continued to own their /usr/X11R6/
*, the DB wasn't changed.  New versions simply moved directly into /usr/, 
and the problem gradually solved itself until it was down to a manageable 
size for a final push to get the old location out of the tree.  (I just 
checked and it appears nothing owns that symlink on my system, now... 
unless I screwed up my equery|grep... )

Now if the symlink somehow gets lost before all packages have moved their 
paths...

But that trick has been used enough in gentoo, especially in gentoo/
amd64, that every PM should cope with it just fine, or said PM would be 
rather broken.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

All,

mgorny has written a patch for udev, which if it gets accepted, will
make it read rules from /lib/udev/rules.d, so there will be nothing that
we need to do on our side at all.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]