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 1SpMDc-00030v-Pz for garchives@archives.gentoo.org; Thu, 12 Jul 2012 16:26:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0BC40E0539; Thu, 12 Jul 2012 16:26:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 99916E0504 for ; Thu, 12 Jul 2012 16:25:08 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 81926641D4 for ; Thu, 12 Jul 2012 16:25:04 +0000 (UTC) Date: Thu, 12 Jul 2012 12:24:44 -0400 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: udev-rules.eclass Message-ID: <20120712122444.076a584f@gentoo.org> In-Reply-To: <20120711234808.GB27226@linux1> References: <20120711191142.GA26844@linux1> <20120711165911.1428ddb6@gentoo.org> <20120711234808.GB27226@linux1> Organization: Gentoo X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 495329f4-1dde-4dd3-891f-414f21d54e93 X-Archives-Hash: 0b8efacc1171061968d4c71ddaafbc99 On Wed, 11 Jul 2012 18:48:08 -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. this sounds heavy for only changing the location of a file, but that's the only sane solution i can think of :( A.