On Sat, Sep 05, 2009 at 11:02:51AM +0200, Hendrik Sattler wrote: > Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: > > On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: > > > And it is also very unclear to me why this has to be in /lib/udev at > > > all.
> > Because it provides a single point where the desktop hooks into the kernel > > hotplug event system, instead of having hal redo all the work already done > > by udev. /That/ much has a sound rationale, even if reading text databases > > in does not. > It's still no rationale at all to use libglib. Which is not the question I was answering. But if you were just having a rhetorical rant instead of trying to understand, then ok - noted. The rationale for this /using glib/ is that devicekit-disks is not an integral part of udev, it's an add-on component that will be installed only on desktop systems. So the size impact to /lib for servers for this component would be negligible; the total size impact of pulling in libglib on the desktop is zero; and the size impact to /lib for desktops is almost certainly also negligible. The upshot is that we almost certainly will have to move glib to /lib, because there's no way we're going to persuade the devicekit authors that they should avoid using libglib when it's already in /lib on all the systems they care about (so it's not an FHS violation anyway), and I don't think you're going to find anyone willing to maintain a devicekit fork either. (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
