-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 2017-11-21 at 18:09 +0000, Tomasz Kłoczko wrote: > On 21 November 2017 at 16:36, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > [..] > > > > > > Counting numbers of affected packages by guessing is very bad idea. > > > > > > > > > > Call it educated guess if you want. > > > > > > > > You know, there is a way to get more reliable data: do scratch builds > > > > of > > > > all Fedora packages and analyze the results. Then we'd know _exactly_ > > > > how many packages would need to be patched. > > Yes of courses. Alternatively quite precise data could be generated by: > > a) build modified fedora-rpm-macros package and after this will be > possible to rebuild all Fedora packages to check which one are > failing. Such list of failing packages it will be necessary to compare > with koji data to remove those which is already known that they are > failing and on left list will be necessary to do one by one analyse to > identify those which are failing by add --as-needed to the linker > options. Still this list could be not 100% accurate as all Fedora > packages are constantly changing. You can do this if you have time and > other resources. > > b) it is possible as well to take all current binary packages to > extract all elf binaries. After such extraction is possible to feed > database about list of all used and provided SONAMEs, list of all > external public symbols used and provided by each elf binary. After > analyse those data will be be possible to say: > 1) which one binaries are linked with to many SONAMEs > 2) which one binaries are still using some symbols which are available > only on run-time stage by indirect linking with libraries which are > linked with to many other libraries (AKA underlinking) > 3) such static analyse can catch all possible run-time symbols clashes > > Such statistic analyser/processor maybe it would be good to have in > Fedora but it would require relatively big investment into development > to catch probably only few cases each year. > ******** > Such effort to develop new infrastructure is way bigger than just > start use --as-needed by default then rebuild everything and at the > end fix only few new failing packages affected by use indirect > run-time linking. *** This way is WAY EASIER. Full stop *** > ******** > > > > ...depending on how thoroughly the analysis is done, as the breakage > > > caused > > > by an erroneous --as-needed might, at least in principle, only happen at > > > runtime, rather than at build time. > > > > Pretty much all software in Fedora is already shipped in other distros > > which have taken this linking approach for a long time. So it is pretty > > reasonable to expect these kind of bugs have been identified & fixed > > by maintainers in other distros already. There may be edge cases remaining > > which no user has yet managed to tickle, but that's true of many aspects > > of Fedora. eg when we introduced the hardened build flags, there were > > places where we wouldn't know about breakage until much later. Requiring > > perfection before making this kind of change effectively means never doing > > the change. > > Guys I'm really appreciate that you are still thinking about some > technical aspects or other things not related straight to Fedora. > As I wrote (IMO) now main obstacle is not technical and it is more > about "which buttons needs to be pushed in Fedora to make it happen?" > Looks like no one want to put wood under this furnace and this is why > this inferno^KFedora packages have tenths of thousands bogus SONAME > dependencies still dangling between the packages. > When this will be implemented in Fedora maybe as well it will be > easier to convince binutils maintains to remove all --as-needed > optional code and leave this option as kind of void option. You keep ignoring me saying that **someone** needs to go through Change Proposal procedure. https://fedoraproject.org/wiki/Changes/Policy > > And again: the same issue is with ldconfig file trigger which needs to > be added to glibc. > This few lines glibc spec improvement can reduce install or upgrade > packages time by at least 20% (less memory on the system or slower > storage than impact will be even bigger) by not wasting time on > ldconfig multiple time executing in every packages with libraries > scriptlets. > This change as well is about regain a lot of time and IOs on Fedora > build infrastructure. You can submit Change Proposal too and if FESCo will approve change and glibc maintainers will not have something strongly against - this will happen. I know, this is some piece of bureaucracy, but it's rather good than bad. - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloUcDQACgkQaVcUvRu8 X0zMChAAukrKydOjxa0htwFPZ0Yt9wupIto/LNsCSqDZEBww+qfYF43mits1RIZX Cddj/iHfMhpFYEex58pTdxAN8Q4HrIDZqvGteyhrBcxKCzEOeal53Xtg9N26TZeA JB5m5ZLqMe2i0gdzMjTvzODWZ1c7GK5fRF8GpFCXrynLG9J00Pg2FwK5H/k7FglM jjcjfWzH8AieyzFyVuBVYRDHjbOve9fKyyx2JUMKDpmf8Q7CVVOLI3SENdh5x1NJ 6i0ia2b/Hl8crgIzDdfSoqcZ0HrLpEukEF9vlLR5rdxLArLD8ddxHGyuZv8MxgsE 4zqwnvXBsUzrHHka5ZwVc+tIw+TpH3s/OcjCqU0RUQzTpERyatCIPuhlUjCOmX8/ Ei9ODaboLzsr/2IkpoOuXt5rqHA/RQPbYIY+zu/2qNc4QGavSw/gW6DUsViiyqUg VsHRAGg/Y1SmuE35CNDJaeZgUPkY0wPd6Em1S9Loa0ETdxBj1Q5slTgBMMeqgFbN hzF5VMvOoPZif3m0L9CB/ATltUwIJrZO/yn7xIb1EfNRQSUiE/IqF7TnbAj5nIyN 8P3JT26Y/H/cI7Fd/JLMQaTGrkZzdrX7NrkfJI/ghk1w8wPJeh1qUV9BGuHyv8Q0 KyZxWgx9RDPF77RUfvLCZgqn7GQl/WroS01d53UATg8H6M6lQlE= =Hpk0 -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
