[opensuse-packaging] How to use gcc49 at OBS
Hi to all! 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)". By the way gcc49 isn't my goal, I would like to make a clang build with gcc 4.9' environment so any tips are welcomed. -- 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
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 --
Hat mich etliche graue Haare gekostet. Kriegt man in solchen Fällen eigentlich von SuSE ne Packung Haarfärbemittel ;-) Ja - aber nur in grün ;-) [> Jürgen Jentsch und Peter Geerds in suse-linux]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz <opensuse@cboltz.de> 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 Mon, 15 Dec 2014, Dmitriy Perlow wrote:
Christian Boltz <opensuse@cboltz.de> 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.
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. 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). Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg) -- 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 <opensuse@cboltz.de> 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 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. -- 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, 16 Dec 2014, Michael Schroeder wrote:
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.
The question is what is so special about "preinstall" - IIRC it's to be able to run the rpm command inside the chroot? (why is it not run from outside, that is, why do we need preinstall at all?) 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'. That way the mechanism to change libgcc_s1 to libgcc_s1-gcc49 is to simply BuildRequire: gcc49 Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg) -- 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
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) -- 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
participants (5)
-
Christian Boltz -
Dmitriy Perlow -
Jan Engelhardt -
Michael Schroeder -
Richard Biener