From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1Sp9hR-0003r1-Q5 for garchives@archives.gentoo.org; Thu, 12 Jul 2012 03:04:18 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5DC88E0128; Thu, 12 Jul 2012 03:04:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E8004E074E for ; Thu, 12 Jul 2012 03:03:18 +0000 (UTC) Received: from [192.168.107.2] (15.sub-75-197-8.myvzw.com [75.197.8.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id 0E0651B400D for ; Thu, 12 Jul 2012 03:03:17 +0000 (UTC) Message-ID: <4FFE3E9A.3030902@gentoo.org> Date: Wed, 11 Jul 2012 23:03:54 -0400 From: "Rick \"Zero_Chaos\" Farina" User-Agent: W1®&M/-\¡1/4.2.9 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: udev-rules.eclass References: <20120711191142.GA26844@linux1> <20120711165911.1428ddb6@gentoo.org> <20120711234808.GB27226@linux1> <4FFE3588.1060101@gentoo.org> <4FFE3B82.6030807@gentoo.org> In-Reply-To: <4FFE3B82.6030807@gentoo.org> X-Enigmail-Version: 1.3.5 X-Mailer: =?ISO-8859-1?Q?4=7C7P=AC3_W1=AE=26M/-=5C=A11?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 902ab18d-1b6a-48fc-9d3f-51ad5335a2cb X-Archives-Hash: 09b6ce6511ce7876edf1069ab695fde2 -----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-----