On 21 November 2017 at 16:36, Daniel P. Berrange <berra...@redhat.com> 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. 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. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
