On 01/07/15 14:39, Matthias Klose wrote: > On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: >> On 25/06/15 17:44, Matthias Klose wrote: >>> On 06/25/2015 01:20 PM, Matthias Klose wrote: >>>> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: >>>>> - You suggest that some libraries may need to be renamed due to the ABI >>>>> breaks. >>>>> Do you have a list of affected libraries? >>>> >>>> No. Getting this list is a bit difficult. Candidates for these packages >>>> are the >>>> GCC 5 build failures due to mismatched symbols files. However there may be >>>> more >>>> packages which successfully build, but have additional symbols (this may >>>> be an >>>> empty set, because usually some symbol names should be just replaced by >>>> new ones). >>> >>> If symbol versioning is used in a library, you probably won't see this at >>> all, >>> until the package is built using GCC 5. I'll ask for another test rebuild >>> with a >>> diverted dpkg-gensymbols to look at the generated symbols files. >> >> Thanks Matthias. I'd be very interested in knowing more about what breaks. > > We have 361 C++ libraries which define at least one of these new symbols [1]. > Note this list only includes the packages which succeed to build with GCC 5. > Another 70 packages might need the same action (the issues at [2] with > severity > important, which fail during the dpkg-gensymbols call). > > So my proposal would be to file bug reports for each of these packages, asking > the maintainers for what to do with this library. Actions could be: > > - do nothing, if none of these symbols are part of the library ABI. That > would be a rebuild of the library and its reverse dependencies. > > - add breaks to all reverse dependencies on this library, and rebuild > the library and the reverse dependencies. > > - rename the library package and rebuild all reverse dependencies. > > The default action should be the most conservative action (the renaming of the > library package).
But let's not do transitions unnecessarily... we have hundreds of libraries there, so if we can avoid a bunch, then we should avoid them. So I'd say the default action should be to investigate if a transition is needed or not. I'm not advocating to blindly ignore the problem, fwiw, just want to try to make this a little manageable. I see there are quite a few FTBFS bugs for the affected libraries, but since the plan is to do the switch to GCC 5 first, and the libstdc++6 transition later, there would be time in between to fix those bugs and prepare for the transition. Right? > These bug reports could be used as transition bug reports as well, once GCC 5 > is > the default. Then these could be reassigned to release.debian.org once the > transitions start. Yeah, that or new bugs. As long as usertags / titles are set properly, I don't mind. :) Cheers, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55956ab2.8030...@debian.org
