On Sunday 27 December 2015 15:43:59 Dmitry Shachnev wrote: > Hi Lisandro, [snip] > My script (debian/scripts/migrate-symbols.py in qt56-symbols branch) is > *much* smarter than plain sed -i 's/@Base/@Qt_5/g'.
I have no doubt in that. My intention wasn't to check your branch but to check if the change in the version node  from Base to Qt_5 would make apps compiled against Qt 5.5 fail to be linked against Qt 5.6. Good news is that everything still works.  <http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html> On a side note this feature is analogous to what our symbols files do . But that doesn't means we should drop symbols files ;)  <https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html> > Its algorithm is: > > 1. Get the list of symbols in new libraries based on the build log. > > 2. For each symbol in the symbols file, check if that symbol exists in the > new libraries. > > - If it exists, changes the version part of the symbol to Qt_5 or > Qt_5_PRIVATE_API, depending on what's found in the new library. > > - If it doesn't exist, leaves it unchanged (maybe the symbol is for > another architecture) so that we can process it the usual > symbolshelper- based way. > > 3. For each old symbol that has disappeared, and is not optional or private, > warns that it is removed. For qtbase its output is: > http://paste.debian.net/355955/ > > And yes, changing the version part of the symbols does not break the ABI, > however removing the old symbols does (so we need to be careful). > > > So I think it's safe to go ahead with the changes. > > So are you OK with merging my branch? :) I was talking about the upstream change in symbols' nodes :) But let me check the branch (done, see below). > I have just updated it based on i386 build log. > > > Dmitry: we still need to look for private symbols as we used to, IIRC > > there > > where some cases of upstream not marking private symbols as such. having > > both methods at hand will surely catch those cases. > > However I also know that our current algorithm has some false positives — > i.e. it marks functions using *pointers* to private objects as private, even > if they are part of public API. I thought that by fully switching to > upstream algorithms, we will get rid of that bug. Do you have an example of such a case? The script was being run over private headers only, so even pointers to private functions should be private. > Do you have any examples of "upstream not marking private symbols as such"? Forget that, I mixed stuff. The symbols are marked as private by using a list created by syncqt.pl, so things should be fine. > In any case I think we should keep the logic in pkg-kde-tools package, i.e. > replace the existing script with mine or extend its logic. I hope Python > dependency is not a problem, is it? I'm totally for it. If it becomes a problem for someone we can consider generating a new binary package from the same source and adding the python dependency there. We might even do that from the beginning. > P.S. I will be offline most of today, will be able to look at anything only > tomorrow (MSK time). And of course I'll be AFK tomorrow, maybe come back online late on ARST's night. Gah, timezone are hard for us :) OK, I've checked the branch and I merged it to experimental. Please do not forget to add the proper copyright headers to the scripts. Should we keep the merging script? I think having it on git's story should be enough. I also don't mind shipping it once in the packages. -- 15: Que es el "Correo Electronico" * El correo que te llega por la corriente Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Description: This is a digitally signed message part.