On 05/20/11 11:39, Michal Soltys wrote:
W dniu 19.05.2011 10:42, Juergen Daubert pisze:
On Wed, May 18, 2011 at 10:19:14AM +0200, Michal Soltys wrote:
Hello Michal,
W dniu 16.05.2011 19:19, Juergen Daubert pisze:
Hi all,
the latest pkg-config, version 0.26, no longer ships with a bundled glib but depends on a system glib. That means core/pkg-config would depend on opt/glib, which is of course not acceptable.
We have two options IMO:
a) move pkg-config to opt. At a first glance I don't see any core-port depending on it, so this should work. The drawback is, that every opt/contrib-ports which has pkg-config as a (buildtime-)dependency must list it in the dependency header. b) move glib to core.
Opinions?
I don't like b), I always prefer to have the fever the better ports in the core collection, so move pkg-config to opt would be fine to me (at first sight), but since CRUX is a source based distro and most ./configure scripts make calls to $PKG_CONFIG we should keep pkg-config in core. After explain that, I also discard a). I prefer to try more options: c) create a patch for pkg-config to have a bundled glib and avoid using system glib, could be that possible? more ideas?
Though I'm not a dev, I'd opt for (b). Apart from pkg-config, at least one more package could depend on glib moved to the core as well (udev).
Thanks for your contribution, even if you are not (yet) a official CRUX maintainer, at least the udev port is your main work ;)
What's the benefit if we enable udev options that depends on glib? Do we really need that? Is this a requirement for stuff like gnome?
gnome, xfce, etc.
Well, whole gui stuff is really not my thing, but from what I can find - it enables creation of a wrapper library around libudev (libgudev), that is used by glib stuff needing interaction with devices. Some of this stuff adds their custom udev rules during installation as well.
Example: colord - which detects hardware calibrators via libgudev. It also installs few udev rules. Previously it was part of gnome color manager (which now depends on it).
How important is that or if it's really required or just optional for gnome in general - tough for me to say. Though anything "modern" interacting with devices and based on glib will likely require it to function properly (if it's possible to compile them without that dependency at all).
Hmm, if udev depends on glib, wouldn't it be better to install the required glib libraries into /lib instead of /usr/lib?
The reason was to keep developer stuff under /usr, while keeping just the runtime stuff under / (similary to what what is done with udev, or other libs needing to be present without /usr - glib is not that small thing after all). OTOH - how many "fatter" glib+udev dependent packages (with custom udev rules added) would be wise enough to not want stuff from /usr is another thing ... (udev itself wants stuff from /usr with one extra, though there're workarounds for /usr problem).
Recent (post-168) udev versions also have fine grained controls instead of just single enable/disable extras. So there's a bit more regarding that subject (potential explicit dependency on acl, usbutils, pciutils - of which all are in core either way, but that's for different thread, along with a few other things).
Just a note about gudev (libgudev), we started a talk related to gudev sometime ago: http://crux.morpheus.net/irc/?channel=crux&date=10Mar2011 Also, ATM you can find a gudev port on xfce repository, but we could move it to opt http://crux.nu/gitweb/?p=ports/xfce.git;a=commit;h=8621f8e8670a773b387cf075f... Is that enough to you? Best regards, -- Jose V Beneyto | http://sepen.mine.nu/