Cristian Morales Vega wrote:

2009/7/7 Pavol Rusnak :

...

...

I don't know exactly what policy you use to add them (I suppose you don't add them for released/fixed products as openSUSE < 11.2), but anyway some I use...

%if 0%{?fedora_version} Substitute: libexpat-devel expat-devel Substitute: libpulse-devel pulseaudio-libs-devel Substitute: pkg-config pkgconfig %endif You can use pkgconfig in SUSE packages too (our pkg-config provides the

Cristian Morales Vega wrote: pkgconfig symbol).

I know, but I suppose that will be removed at some point. Looking into it, that provides could already be removed. The pkgconfig -> pkg-config rename is from openSUSE 10.2->10.3, no supported version still uses pkgconfig.

I was told that this symbol is not going to be removed, because we are keeping it not only for openSUSE 10.2 and older, but also for compatibility with Fedora/Mandriva. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega wrote:

2009/7/7 Pavol Rusnak :

...

Cristian Morales Vega wrote:

...

2009/7/7 Pavol Rusnak :

...

Cristian Morales Vega wrote:

...

I don't know exactly what policy you use to add them (I suppose you don't add them for released/fixed products as openSUSE < 11.2), but anyway some I use...

Thinking more about this, I see no cause to avoid adding new Subtitutes to openSUSE:11.0 or openSUSE:10.3.

Me neither, I was not suggesting not to add the Substite.

...

...

...

...

%if 0%{?fedora_version} Substitute: libexpat-devel expat-devel Substitute: libpulse-devel pulseaudio-libs-devel Substitute: pkg-config pkgconfig %endif You can use pkgconfig in SUSE packages too (our pkg-config provides the pkgconfig symbol). I know, but I suppose that will be removed at some point. Looking into it, that provides could already be removed. The pkgconfig -> pkg-config rename is from openSUSE 10.2->10.3, no supported version still uses pkgconfig. I was told that this symbol is not going to be removed, because we are keeping it not only for openSUSE 10.2 and older, but also for compatibility with Fedora/Mandriva.

Maintain compatibility in cases of different package name isn't exactly why Substitute exists? Why pkg-config is special? If we are going to have to use "pkgconfig" to maintain compatibility with other distros then the rename in openSUSE didn't make much sense to start with.

Anyway, will any of them be added? I ask because I "need" (I could use #ifdef in the spec file, but the Substitute way seems better to me*) the gstreamer and xine ones for a package from KDE:KDE4:Community. If they are going to be in the root repos I can just wait.

* I get a cleaner spec file. And we have a *single* database of differences between distro for the day we want to talk to them and unify the names.

-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/7/10 Adrian Schröter :

Am Freitag, 10. Juli 2009 11:47:53 schrieb Pavol Rusnak:

...

Cristian Morales Vega wrote:

...

2009/7/7 Pavol Rusnak :

...

Cristian Morales Vega wrote:

...

2009/7/7 Pavol Rusnak :

...

Cristian Morales Vega wrote: > I don't know exactly what policy you use to add them (I suppose you > don't add them for released/fixed products as openSUSE < 11.2), but > anyway some I use...

Thinking more about this, I see no cause to avoid adding new Subtitutes to openSUSE:11.0 or openSUSE:10.3.

Me neither, I was not suggesting not to add the Substite.

...

...

...

...

> %if 0%{?fedora_version} > Substitute: libexpat-devel expat-devel > Substitute: libpulse-devel pulseaudio-libs-devel > Substitute: pkg-config pkgconfig > %endif

...

...

...

...

You can use pkgconfig in SUSE packages too (our pkg-config provides the pkgconfig symbol).

I know, but I suppose that will be removed at some point. Looking into it, that provides could already be removed. The pkgconfig -> pkg-config rename is from openSUSE 10.2->10.3, no supported version still uses pkgconfig.

I was told that this symbol is not going to be removed, because we are keeping it not only for openSUSE 10.2 and older, but also for compatibility with Fedora/Mandriva.

Maintain compatibility in cases of different package name isn't exactly why Substitute exists? Why pkg-config is special? If we are going to have to use "pkgconfig" to maintain compatibility with other distros then the rename in openSUSE didn't make much sense to start with.

Anyway, will any of them be added? I ask because I "need" (I could use #ifdef in the spec file, but the Substitute way seems better to me*) the gstreamer and xine ones for a package from KDE:KDE4:Community. If they are going to be in the root repos I can just wait.

It has down and up sides, adding them will help for all new packages and new users definitivly.

The downside is that it will break projects, which build the new package names for the old distro and depend on them. They will suddenly break when I add these substitutes, because now the "old" one from the distro will be used instead of the new one in their projects (or in some mid-level projects like KDE:Factory). It can of course get fixed again by adding lines to the project config of these projects.

So, the question is if we want to keep base distros as stable as possible for people building against or if we want to map as much as possible.

I am quite unsure what to do here ...

OK, I was sure it would be some problem... But I would say this would be a packaging problem... even if I'm not sure about how the BS handles this. While the old distro is still maintained any package renamed should still "provide" the old package name. So, even with the substitute, shouldn't the new package be selected by the BS? And if the package *really* needs the latest version of the package then it should be stated explicitly in the spec file, there would not be any ambiguity for the BS about which package it should select. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org