From: md@Linux.IT (Marco d'Itri)
To: linux-hotplug@vger.kernel.org
Subject: Re: make glib optional
Date: Sun, 23 Aug 2009 16:52:22 +0000 [thread overview]
Message-ID: <20090823165222.GA4625@bongo.bofh.it> (raw)
In-Reply-To: <20090822033634.GA2669@bongo.bofh.it>
On Aug 23, Lennart Poettering <lennart@poettering.net> wrote:
> This patch is incredibly ugly, and broken. The most obvious issue is
> for example that on Fedora glib is in /lib, and on multilib machines it is
> even in /lib64.
It does not pretend to be universal, it was just a proof of concept for
the initial packaging. I already have a version which uses ldd to find
out the library name.
> If you dislike glib that much then I'd suggest splitting off udev-acl
> and the rules files into a seperate package and then have ckit depend
> on it. But this explicit check you suggested is just failure.
The point is not disliking glib, but disliking gratuitously inflating
the base system of 2 MB when it can easily be avoided.
Debian officially supports much more than desktop/server systems, and
many of them have no use for ConsoleKit. Even popularity-contest (whose
statistics are biased against smaller/embedded systems) shows that while
udev is almost universal, glib is not installed on 15% of the sample:
http://qa.debian.org/popcon-graph.php?packages=udev+libglib2.0-0+module-init-tools&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
I considered generating another binary package just for udev-acl, but it
seemed overkill for an 8 KB program. I still think it would be simpler
to just make it part of ConsoleKit since it has no use without it.
--
ciao,
Marco
prev parent reply other threads:[~2009-08-23 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-22 3:36 make glib optional Marco d'Itri
2009-08-22 11:51 ` Kay Sievers
2009-08-22 12:02 ` Marco d'Itri
2009-08-22 12:09 ` Kay Sievers
2009-08-23 13:42 ` Lennart Poettering
2009-08-23 16:52 ` Marco d'Itri [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090823165222.GA4625@bongo.bofh.it \
--to=md@linux.it \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).