From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: [PATCH] add a way to disable xen's udev script. Date: Thu, 9 Jun 2011 10:01:40 +0100 Message-ID: <4DF08BF4.3010904@eu.citrix.com> References: <4DEFA993.1020803@eu.citrix.com> <1307554945.4176.47.camel@dagon.hellion.org.uk> <4DEFCC40.3000103@eu.citrix.com> <1307562567.4176.57.camel@dagon.hellion.org.uk> <4DEFDCB5.4020301@eu.citrix.com> <1307605345.775.758.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1307605345.775.758.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 06/09/2011 08:42 AM, Ian Campbell wrote: > and of course working with the maintainer of the package you wish to > integrate with is clearly out of the question? This is an upstream issue in the first place. The assumption that everyone is supposed to use those *globally* installed udev scripts that are targeted to xend and to some extent xl, is simply false. While i used the debian package as an example, the same is true for every other xen packages that i looked at. And adding a Conflicts entry is just not a solution either, since you need install/removes packages (and restarting udev) to switch toolstacks whereas my solution involves no such thing. In any case, installing multiple toolstacks in parallel would *have* to have a *dynamic* way to execute different udev scripts, which I might argue that's exactly what i provide in a very simple way with a dummy file mechanism (not ideal mechanism, but just does the job trivially). >> There's more than likely a perfect way to splice the packages to make it >> a package issue only, however I'm not terribly interested in putting >> more efforts than a *trivial* 1 line change. > > Sorry, but I don't think you motivation or lack thereof justifies adding > this sort of hack to the upstream Xen code base. Please. joking so early ! Those scripts are hacks in the first place, and are taking advantages of udev flexibility to do horrid stuff. -- Vincent