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