[Libosinfo] [PATCH] Ditch udev rule

Zeeshan Ali (Khattak) zeeshanak at gnome.org
Tue Sep 10 13:25:39 UTC 2013


On Tue, Feb 19, 2013 at 12:11 PM, Daniel P. Berrange
<berrange at redhat.com> wrote:
> On Tue, Feb 19, 2013 at 04:13:06AM +0200, Zeeshan Ali (Khattak) wrote:
>> On Mon, Feb 18, 2013 at 6:47 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> > On Mon, Feb 18, 2013 at 06:33:08PM +0200, Zeeshan Ali (Khattak) wrote:
>> >> On Mon, Feb 18, 2013 at 6:20 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> >> > On Mon, Feb 18, 2013 at 05:22:23PM +0200, Zeeshan Ali (Khattak) wrote:
>> >> >> From: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
>> >> >>
>> >> >> New udev/blkid expose more ISO9660 properties that apps can grab and
>> >> >> set on install media for detection to work. As a result our udev rule
>> >> >> becomes redundant.
>> >> >>
>> >> >> This improves system bootup time conciderably if there is an ISO9660
>> >> >> media inserted during bootup as our udev rule needed to parse the XML
>> >> >> etc and is therefore pretty slow (keeping in mind that a few seconds are
>> >> >> a long time in the land of modern udev/systemd).
>> >> >
>> >> > ACK, I never liked this rule existing in libosinfo in the first
>> >> > place.
>> >>
>> >> Cool. Since merging this before systemd release would mean breaking
>> >> unattended installations in Boxes (and a few other things), lets merge
>> >> this after systemd release (expected in a week).
>> >
>> > Well that's assuming people are installing these in lockstep which
>> > is not required. This dependancy is merely a distro packager or
>> > documentation issue. There's  no need to hold off putting this in
>> > libosinfo
>>
>> I'm fine with both keeping the rules for now and ditching it already.
>> I'll let you and Christophe convince each other.
>
> Keep it for now, but update the RPM specfile so that if built for
> Fedora 19, it is not installed.

So is it now time to merge this patch before we forget about it completely?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124




More information about the Libosinfo mailing list