It seems that the solution for bug #246556 made dev-util/pkgconfig a dependency of net-misc/wget. Unfortunately, dev-util/pkgconfig depends on glib, which is a rather heavyweight package. Is there any possibility that we could eliminate this dependency by either revisiting the solution to bug #246556 or replacing pkg-config with an equivalent. At present, we have dev-util/pkgconfig-openbsd in the tree. There is also pkg-config-lite: http://sourceforge.net/projects/pkgconfiglite/
bug 246556 was just fallout of fixes that wget should have regardless. pkg-config is only going to be required more and more by things, so adding something specific to wget won't really help, just delay. maybe we should add a virtual/pkgconfig and have these various pkg-config implementations provide it. also, this is DEPEND only. wget does not RDEPEND on pkgconfig.
bottom line is that pkgconfig's glib usage is fine and that we wont deviate from freedesktop.org standard pkg-config. (i've added dev-util/pkgconfig-openbsd in tree for people to use in own experiments, it doesn't work for all of the packages by long shot. no way it is ready to go into any virtual)
that isn't the only choice. a virtual/pkgconfig would be useful.
But looks like pkgconfig-openbsd won't work for a lot of packages (and then, it wouldn't fit in virtual package as it's not equivalent), and pkgconfiglite is like pkg-config but using bundled glib (like pkg-config <0.25 did until it was moved to use system libs as usually preferred)
We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a sane replacement for fd.o pkgconfig with the only dependencies being a C89-compliant compiler and popt. It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. [1]: http://git.atheme.org/pkgconf/
(In reply to comment #5) > We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a > sane replacement for fd.o pkgconfig with the only dependencies being a > C89-compliant compiler and popt. > > It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to > think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. > > [1]: http://git.atheme.org/pkgconf/ "EDIT:" It is currently used as the pkgconfig implementation in Alpine Linux and it seems to work fine for them so it's fairly safe to assume it'd work for us too.
(In reply to comment #6) > (In reply to comment #5) > > We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a > > sane replacement for fd.o pkgconfig with the only dependencies being a > > C89-compliant compiler and popt. > > > > It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to > > think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. > > > > [1]: http://git.atheme.org/pkgconf/ > > "EDIT:" It is currently used as the pkgconfig implementation in Alpine Linux > and it seems to work fine for them so it's fairly safe to assume it'd work > for us too. This would prevent dev-libs/glib from being pulled into the Gentoo/FreeBSD @system set and prevent a possible circular dependency in Gentoo Prefix.
no and no. we won't deviate from the freedesktop.org standard pkg-config, the cons outweight the pros multiple times
(In reply to comment #5) > We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a > sane replacement for fd.o pkgconfig with the only dependencies being a > C89-compliant compiler and popt. > > It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to > think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. then pkgconf is broken if it doesn't respect the freedesktop.org pkg-config version scheme ordering. the freedesktop.org one is the baseline standard. (In reply to comment #4) > But looks like pkgconfig-openbsd won't work for a lot of packages (and then, > it wouldn't fit in virtual package as it's not equivalent), and > pkgconfiglite is like pkg-config but using bundled glib (like pkg-config > <0.25 did until it was moved to use system libs as usually preferred) and bundling glib back to pkg-config is out of question, we have a policy for not using bundled libraries. pkg-config is perfectly bootstrappable with systems glib. and this leaves us with no other valid providers for the virtual, rendering the whole idea of virtual useless.
(In reply to comment #9) > and this leaves us with no other valid providers for the virtual, rendering > the whole idea of virtual useless. You might want to look at comment #5, which provides a perfectly valid provider: http://git.atheme.org/pkgconf/
(In reply to comment #9) > (In reply to comment #5) > > We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a > > sane replacement for fd.o pkgconfig with the only dependencies being a > > C89-compliant compiler and popt. > > > > It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to > > think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. > > then pkgconf is broken if it doesn't respect the freedesktop.org pkg-config > version scheme ordering. the freedesktop.org one is the baseline standard. What keeps someone from patching the freedesktop.org pkg-config to use a sane version ordering scheme and then sending the patch upstream? Is there anything to suggest that they would not accept it? With that in mind, is using a sane version ordering scheme a valid reason for rejecting it?
make your case on gentoo-dev. the virtual is happening at this point.
(In reply to comment #12) > make your case on gentoo-dev. the virtual is happening at this point. what? virtual is for apps behaving similary, and none of the suggested alternatives do. (In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #5) > > > We could also switch to/support atheme.org's pkgconf[1]. It attempts to be a > > > sane replacement for fd.o pkgconfig with the only dependencies being a > > > C89-compliant compiler and popt. > > > > > > It also fixes pkgconfig stupidity. For example, fd.o pkgconfig seems to > > > think that 2.0.0 !> 2.0.0_alpha1, pkgconf doesn't think this. > > > > then pkgconf is broken if it doesn't respect the freedesktop.org pkg-config > > version scheme ordering. the freedesktop.org one is the baseline standard. > > What keeps someone from patching the freedesktop.org pkg-config to use a > sane version ordering scheme and then sending the patch upstream? Is there > anything to suggest that they would not accept it? With that in mind, is > using a sane version ordering scheme a valid reason for rejecting it? nothing, so while waiting for that patch to be sent out to the freedesktop.org bugzilla and pkg-config mailing list, no virtual is happening.
(In reply to comment #13) yes, they do behave the same
(In reply to comment #14) > (In reply to comment #13) > > yes, they do behave the same They don't, see Comment #5
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > > yes, they do behave the same > > They don't, see Comment #5 They do, pkg-config have the exact same versioning rules that pkgconf does, which are the versioning rules as implemented in RPM. There is no special handling for 2.0.0 > 2.0.0_alpha1 case.
virtual/pkgconfig now exists. will update repoman to warn people to encourage distributed migration.
