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? thanks and best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On Mon, 16 May 2011 19:19:06 +0200 Juergen Daubert wrote:
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?
Since glib depends only on core/libpcre, and most ports from opt/contrib are likely to depend on pkg-config, cleanest/simplest solution would be moving glib to core, imho. btw, are ports from core considered implicit dependencies (should not be listed in Depends field in Pkgfile since it is assumed that there are always installed on a system)?Or are there exceptions to that?
thanks and best regards Juergen
Pedja
Predrag Ivanovic wrote:
On Mon, 16 May 2011 19:19:06 +0200 Juergen Daubert wrote:
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?
Since glib depends only on core/libpcre, and most ports from opt/contrib are likely to depend on pkg-config, cleanest/simplest solution would be moving glib to core, imho. btw, are ports from core considered implicit dependencies (should not be listed in Depends field in Pkgfile since it is assumed that there are always installed on a system)?Or are there exceptions to that?
thanks and best regards Juergen
Pedja _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
As far as I know you do not list any gcc/glibc and friends considered as the tool chain, but you do list ports in core that you link to not things like perl that's not being linked to. say your port foo links to glibc, zlib, perl you only list zlib. Regards, Danny Rawlins <Romster>
On Tue, May 17, 2011 at 11:49:28PM +0200, Predrag Ivanovic wrote:
On Mon, 16 May 2011 19:19:06 +0200 Juergen Daubert wrote:
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?
Since glib depends only on core/libpcre, and most ports from opt/contrib are likely to depend on pkg-config, cleanest/simplest solution would be moving glib to core, imho. btw, are ports from core considered implicit dependencies (should not be listed in Depends field in Pkgfile since it is assumed that there are always installed on a system)?Or are there exceptions to that?
Thanks for sharing your opinion. Our wiki page PortGuidelines [1] defines how dependencies should be handled. Greetings Juergen [1] http://crux.nu/Main/PortGuidelines -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
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?
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). In such case I'd also add to glib's Pkgfile: --with-runtime-libdir=../../lib and probably (though I'm not 100% sure if it's really needed): --with-gio-module-dir=/lib/gio/modules and adjust (just install tends to fail with bigger -jN setting): make -j1 DESTDIR=$PKG install This is healthier for specific apps that require ->udev->glib to work properly before /usr is mounted (for those that mount /usr separately). E.g.: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=18f5c802dfd958d9a...
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?
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?
In such case I'd also add to glib's Pkgfile:
--with-runtime-libdir=../../lib
and probably (though I'm not 100% sure if it's really needed):
--with-gio-module-dir=/lib/gio/modules
and adjust (just install tends to fail with bigger -jN setting):
make -j1 DESTDIR=$PKG install
This is healthier for specific apps that require ->udev->glib to work properly before /usr is mounted (for those that mount /usr separately). E.g.:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=18f5c802dfd958d9a...
Hmm, if udev depends on glib, wouldn't it be better to install the required glib libraries into /lib instead of /usr/lib? Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
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?
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?
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).
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/
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=8621f8e8670a773b387cf075f...
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:jue@jue.li Korb, Germany | http://jue.li/crux
On Fri, May 20, 2011 at 11:39:43AM +0200, 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?
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?
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).
Sorry, that's exactly what I mean: move the glib-libraries required by udev to /lib and leave all the other stuff beneath /usr. The same way we are doing it with libusb or acl for example. Or do I miss something?
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).
Yeah, just had a quick look at new udev 170 and saw that udev-acl depends on glib too and the keymap feature needs opt/gperf at buildtime. Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
W dniu 20.05.2011 14:31, Juergen Daubert pisze:
Sorry, that's exactly what I mean: move the glib-libraries required by udev to /lib and leave all the other stuff beneath /usr. The same way we are doing it with libusb or acl for example.
Or do I miss something?
That's what mentioned option earlier handles: --with-runtime-libdir=../../lib (path is relative to real libdir)
On Fri, May 20, 2011 at 03:46:57PM +0200, Michal Soltys wrote:
W dniu 20.05.2011 14:31, Juergen Daubert pisze:
Sorry, that's exactly what I mean: move the glib-libraries required by udev to /lib and leave all the other stuff beneath /usr. The same way we are doing it with libusb or acl for example.
Or do I miss something?
That's what mentioned option earlier handles:
--with-runtime-libdir=../../lib
(path is relative to real libdir)
my bad, now I got it, thanks Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Juergen Daubert [2011-05-16 19:19]: Hi,
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. [...] b) move glib to core.
I moved glib from opt to core yesterday, applying the changes that Michal suggested to please gudev. Thanks guys, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On 11-05-22 11:27, Tilman Sauerbeck wrote:
Juergen Daubert [2011-05-16 19:19]:
Hi,
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. [...] b) move glib to core.
I moved glib from opt to core yesterday, applying the changes that Michal suggested to please gudev.
Thanks guys, Tilman
One thing I mentioned earlier, the following option: --with-gio-module-dir=/lib/gio/modules I'm really not sure about that one. From glib coding complete outsider's point of view (me) it makes sense to be near runtime, but otherwise I can't back that up with any facts. I don't know how big stuff there can be (and / can be pretty tiny), how exactly is the stuff put there by other apps (and if they actually bother checking if /usr/lib/gio/.... is not used), or if being at all cost in /usr-less / is an issue in this context. Or any other issues one might think off. Keep that in mind :)
participants (6)
-
Danny Rawlins -
Jose V Beneyto -
Juergen Daubert -
Michal Soltys -
Predrag Ivanovic -
Tilman Sauerbeck