Christian Boltz Mon, 15 Dec 2014 23:10:19 +0300:

Hello,

Am Sonntag, 14. Dezember 2014 schrieb Dmitriy Perlow:

...

How gcc49 can be used for oS 13.2? If it is required to build unresolvable state will appear with message "conflict for provider of libgcc_s1 >= 4.9.0+r211729-2.1.7 needed by gcc49, (provider libgcc_s1-gcc49 is conflicted by installed libgcc_s1)".

Try #!BuildIgnore: libgcc_s1

I seem to remember that BuildRequires: -libgcc_s1 is a newer (and recommended) version of that, but can't find a note about it in the wiki. Try it if #!BuildIgnore doesn't work ;-)

Another way could be to change the prjconf using "substitute", see https://en.opensuse.org/openSUSE:Build_Service_prjconf

Regards,

Christian Boltz

"BuildConflicts: libgcc_s1" causes failed state with "libgcc_s1 isn't installed" message. -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Dec 16, 2014 at 10:30:43AM +0100, Richard Biener wrote:

On Mon, 15 Dec 2014, Dmitriy Perlow wrote:

...

Christian Boltz Mon, 15 Dec 2014 23:10:19 +0300:

...

Try #!BuildIgnore: libgcc_s1

I seem to remember that BuildRequires: -libgcc_s1 is a newer (and recommended) version of that, but can't find a note about it in the wiki. Try it if #!BuildIgnore doesn't work ;-)

Uh, "BuildRequires: -libgcc_s1" is *not* recommended. It works because of a side effect in the spec file parser. Please use #!BuildIgnore.

The unfortunate reason for all this is that the OBS code doesn't allow same package names from multiple sources (or rather its behavior is random instead of deterministic). Thus we end up with multiple names for libgcc_s1.

It's deterministic nowadays, the package containers are ordered lexicographically and the first one wins. No randomness involved.

And of course another reason is that libgcc_s1 is in the 'Preinstall' section of the project config which doesn't seem to participate in dependency computation. So if you add BuildRequires: gcc49 then even the fact that libgcc_s1-gcc49 does satisfy a 'libgcc_s1' dependency doesn't help, because Preinstall is interpreted as a list of packages rather than an additional source of dependencies.

Not sure if any of the above can be improved to make it easier to support a BuildRequires of a non-system gcc. Michael?

I've used project-config hackery to get around this usually (but I've only had the need to switch compilers project-wide, not per package).

Yes, I think it's currently not possible to mess with the preinstalls on a per-packages basis. So you can't get rid of libgcc_s1 without changing the project config. Sorry, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX 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 To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Dec 16, 2014 at 02:19:13PM +0100, Jan Engelhardt wrote:

On Tuesday 2014-12-16 13:33, Michael Schroeder wrote:

...

...

because Preinstall is interpreted as a list of packages rather than an additional source of dependencies.

Not sure if any of the above can be improved to make it easier to support a BuildRequires of a non-system gcc. Michael?

Yes, I think it's currently not possible to mess with the preinstalls on a per-packages basis. So you can't get rid of libgcc_s1 without changing the project config.

In fact, if Preinstall were to be a solvable, we would not even need Preinstall: libgcc_s1, but could source things through Preinstall/Requires: somethingelse.

You mean we should run the dependency solver for some small "preinstall" set, so that we don't need to list all libraries? We could do that, but we also need a way to change the list from a specfile. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX 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 To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Dec 16, 2014 at 03:17:29PM +0100, Richard Biener wrote:

That said, preinstall should be a solvable but solving should be together with all others (support, buildrequires, etc.) - and the final preinstall should simply be filtered from the result by means of minimizing the solution with the requires set as written in 'preinstall'.

Patches welcome ;) M. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Dec 16, 2014 at 06:18:47PM +0100, Jan Engelhardt wrote:

...

...

In fact, if Preinstall were to be a solvable, we would not even need Preinstall: libgcc_s1, but could source things through Preinstall/Requires: somethingelse.

You mean we should run the dependency solver for some small "preinstall" set, so that we don't need to list all libraries? We could do that, but we also need a way to change the list from a specfile.

Well, we have BuildRequires: this -that for specfiles, don't we? (Or BuildIgnore, or whatever else floats the boat currently)

Hey, "BuildRequires: -that" *never* was the official way to specify conflicts. And it does something different than you think: it tell the solver to *ignore* the dependency. You want the dependency fulfilled, but with a different package. There's currently no way to do that. M. -- Michael Schroeder mls@suse.de SUSE LINUX 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 To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org