El 16/05/11 13:58, Yamaban escribió:

On Mon, 16 May 2011 18:24, Greg Freemyer wrote:

...

On Mon, May 16, 2011 at 7:25 AM, Vincent Untz wrote:

...

Hi,

pkg-config 0.26 is out and one of the changes is the removal of an internal copy of the glib code. That means that pkg-config now requires glib to build. However, glib requires pkg-config to build. Hence a fun build loop.

Does anyone have any idea how we should deal with this situation?

Thanks,

Vincent

Brainstorm only:

Can you have glib depend on an older version of pkg-config that still has its own glib?

That sort of "fix" might even last for years before glib depends on new pkg-config functionality.

Still not a very clean way to do things, since you need both the old static pkg-config package in factory as well as the new one.

Greg

Food for tought:

- How do they build pkg-config upstream? - Don't they have the same trouble?

None the less, could a static glib for pkg-config be the temporal answer for us? - at least until upstream has a solution?

Build loops are not problem of upstream, but of distributions. static linking is not a solution either. Probably removing the need of pkgconfig for building glib is better solution, it only requires pair of libraries... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, May 16, 2011 at 05:58:09PM +0100, Tejas Guruswamy wrote:

On 16/05/11 12:25, Vincent Untz wrote:

...

pkg-config 0.26 is out and one of the changes is the removal of an internal copy of the glib code. That means that pkg-config now requires glib to build. However, glib requires pkg-config to build. Hence a fun build loop.

Does anyone have any idea how we should deal with this situation?

Thanks,

Vincent

Surely the OBS can deal with build loops by simply using the last successful build of a package?

Yes, of course. But see below.

I'm sure there are other build loops in the distribution ...

A build loop has two big disadvantages: - it increases build time, as the packages have to be built twice - it makes a bootstrap much harder, e.g. when there's an incompatible change or the soname of a library changes. So, the rule of thumb is: avoid cycles if possible. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am Montag, 16. Mai 2011 schrieb Cristian Rodríguez:

El 16/05/11 07:25, Vincent Untz escribió:

...

Hi,

pkg-config 0.26 is out and one of the changes is the removal of an internal copy of the glib code. That means that pkg-config now requires glib to build. However, glib requires pkg-config to build. Hence a fun build loop.

Does anyone have any idea how we should deal with this situation?

Thanks,

Vincent

This has to be fixed in the project configuration, I know you can break loops there, but I dont recall exactly how atm.

You can only break artificial loops. This one is real. When bootstrapping you have to have both, so it's real. I only see two solutions (both are ugly): * Merge the Sources into one package and have pkg-config build as subpackage from glib (or the other way around) * avoid pkg-config in glib Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Tue, 2011-05-17 at 14:35 +0200, Stephan Kulow wrote:

You can only break artificial loops. This one is real. When bootstrapping you have to have both, so it's real.

I only see two solutions (both are ugly):

* Merge the Sources into one package and have pkg-config build as subpackage from glib (or the other way around) * avoid pkg-config in glib

Avoiding pkg-config in glib2 is not really difficult. It checks for only 4 things using pkg-config: * zlib * libffi * libpcre * dbus-1 => zlib does not depend on the .pc file. configure gracefully falls back in finding headers and libs in standard paths. No lost functionality. For libffi: the .pc file we have is 'artificial' anyway (but we do have it for other packages too). As the things are in standard paths, adding LIBFFI_CFLAGS and LIBFFI_LIBS env before configure gets it going The same is true for libpcre. Easy to 'simulate' As for dbus-1: I can't see any reference in current builds that this would be enabled generally... it is not being built with the existing packages. from the build log: checking for DBUS1... no Additionally we will have to add the pkgconfig() provides manually, as this is also provided pkg-config magic. Should be possible to simulate though. so even though it is not really clean to remove pkg-config from glib2, it would not be really difficult to do so. What are our conclusions on how to proceed? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Tue, 17 May 2011 16:03, Stephan Kulow wrote:

Am Dienstag, 17. Mai 2011 schrieb Dimstar / Dominique Leuenberger:

...

On Tue, 2011-05-17 at 14:35 +0200, Stephan Kulow wrote:

...

You can only break artificial loops. This one is real. When bootstrapping you have to have both, so it's real.

I only see two solutions (both are ugly): * Merge the Sources into one package and have pkg-config build as subpackage

from glib (or the other way around)

* avoid pkg-config in glib

Avoiding pkg-config in glib2 is not really difficult. It checks for only 4 things using pkg-config:

Hmm, after checking: pkg-config is already in the basic bootstrap cycle. So if pkg-config uses glib, glib will be in that cycle anyway. So there is no point in avoid pkg-config in glib.

I wouldn't say that. Either you a) include a striped down / older version of glib in pkg-config source (like the 0.25 version does, no need for glib package in bootstrap), b) make the build of glib independent of pkg-config, to avoid any loops in the bootstrap cycle. This saves time, nerves, and other resources. For both of these solutions, examples / todos where already done in this thread. What remains is to find out if either of these solutions are good enough, or if there is more research needed to decide what to do. No matter how we decide, until we force pkg-config>=0.26 into factory, we have the time to find a working way to resolve this, or it WILL come back to bite us in our behinds, "hello Murphy" on this. Yamaban out. PS: I do not have the expertise do say this or that solution is better, but doing an ostrich doesn't help us any. And yes, bootstraping is ugly. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org