On Fri, May 20, 2011 at 12:45:12PM +0200, Jose V Beneyto wrote: > 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?
Yes, it should be possible, but is it really worth the trouble? I'd say no. At all I'm with you, it's nice to have a slim core collection. But in the case of glib I wouldn't mind to have it in core, because it's a basic library used by a lot of applications. > > more ideas? not really ;) > > >>>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=8621f8e8670a773b387cf075f791d659793826d5 I like the idea to split out the glib dependent part of udev to another port. We should move the port to opt IMO. > Is that enough to you? Yeah :-) Thanks for sharing your ideas, Jose. best regards Juergen -- Juergen Daubert | mailto:[email protected] Korb, Germany | http://jue.li/crux _______________________________________________ crux-devel mailing list [email protected] http://lists.crux.nu/mailman/listinfo/crux-devel
