This package restores the problem of bundled glib from bug 206966 and should therefore be removed from Portage. There is absolutely no problem with bootstrapping original pkg-config and =dev-libs/glib-2* so there is no reason to introduce this regression to the tree.
(In reply to comment #0) > This package restores the problem of bundled glib from bug 206966 and should > therefore be removed from Portage. > > There is absolutely no problem with bootstrapping original pkg-config and > =dev-libs/glib-2* so there is no reason to introduce this regression to the > tree. As per irc #g-dev: 08:22 <@jdhore> and even fd.o pkg-config got so many complaints that they re-added the bundled glib in git (8 days ago)...still... So just wait for next release of pkg-config, and pkg-config-lite won't be the only one;)
(In reply to comment #1) > (In reply to comment #0) > > This package restores the problem of bundled glib from bug 206966 and should > > therefore be removed from Portage. > > > > There is absolutely no problem with bootstrapping original pkg-config and > > =dev-libs/glib-2* so there is no reason to introduce this regression to the > > tree. > > As per irc #g-dev: > 08:22 <@jdhore> and even fd.o pkg-config got so many complaints that they > re-added the bundled glib in git (8 days ago)...still... > > So just wait for next release of pkg-config, and pkg-config-lite won't be > the only one;) They added a switch for building against internal copy of glib which we obviously won't be using and instead stick to building with the external copy.
it's a hand stripped down version, and you've already pointed out why pkg-config doesn't work: requiring glib-2 is unacceptable in some systems.
(In reply to comment #3) > it's a hand stripped down version, and you've already pointed out why > pkg-config doesn't work: requiring glib-2 is unacceptable in some systems. like what systems? show me such an bug, or other reference. just because you don't like glib, doesn't make it a problem.
i think you've mixed things up. i don't like glib-2 because it is a problem: it requires locale/unicode support. if it made that optional, i'd have no problem with it. as for reference bugs, just search for "glib" and "uclibc".
Once freedesktop.org pkg-config gets a release, how do you feel about punting pkg-config-lite in favour of USE flag in dev-util/pkgconfig to use internal copy? This could then be enabled in embedded's profile and we wouldn't need this fork anymore. http://cgit.freedesktop.org/pkg-config/commit/?id=c74da521af566bc208ff9a2da3e43634817f73d5
=dev-util/pkgconfig-9999 with USE=internal-glib in Portage for testing.
i think it's pasically unpacking the glib tarball and running `./configure` in there ? or is there something more to it ? that solves the bootstrap issue, but afaik, the glib configure script will still require locale/multibyte functionality in the host system. while the general glib tarball includes APIs that'll require that, the reduced functionality that pkg-config specifically cares about doesn't. so it doesn't entirely address the pkg-config-lite scenario, although it might placate the peeps who made that mini-fork in the first place, so it's a dead project. and as long as pkgconf exists as an alternative which only requires a C library, i probably won't fight over keeping pkg-config-lite. it's nice as a fallback, but maybe we could address it in a more general way (eglib replacing glib-2?).
(In reply to comment #8) > i think it's pasically unpacking the glib tarball and running `./configure` > in there ? or is there something more to it ? there is these commits: http://cgit.freedesktop.org/pkg-config/commit/?id=7c54f7ca1e9e847a7bba7ede2c4696685af5822f so it looks like as if they were trying to remove as much as possible from the bundled copy. if what you describe below here, still requiring locale/multibyte functionality, is still in place, maybe we could help them out in ripping out more of the bundled copy... > > that solves the bootstrap issue, but afaik, the glib configure script will > still require locale/multibyte functionality in the host system. while the > general glib tarball includes APIs that'll require that, the reduced > functionality that pkg-config specifically cares about doesn't. > > so it doesn't entirely address the pkg-config-lite scenario, although it > might placate the peeps who made that mini-fork in the first place, so it's > a dead project. and as long as pkgconf exists as an alternative which only > requires a C library, i probably won't fight over keeping pkg-config-lite. > it's nice as a fallback, but maybe we could address it in a more general way > (eglib replacing glib-2?).
(In reply to comment #9) i just tried it and it still requires too much. but it seems like patches can be sent upstream to address it (although i wonder why if they're stripping things down they didn't just do what pkg-config-lite has done).
