On Mon, 10 Dec 2007, Matthias Klose wrote: > for all symbols in libgcc1, although that is the unmodified symbols > file taken from seedsymbols. 4.2.2-5 is the new package *source* version that > I'm trying to build. 1:4.2.2-5 is the new binary version of the package. > A version is used/generated which doesn't match the binary package. > > But why are the version names regenerated at all? dh_makeshlibs calls
dpkg-gensymbols updates the files and does not simply install it. Otherwise it would not really be needed. In the update process it add new symbols, remove those which have disapeared and updates the version of those that already exist if the current version is smaller than the listed version. Since gcc is one of the few packages that has differing source and binary versions, the assumption of using the source version doesn't work and it indeed needs to pass the -v$version manually. Thus I agree that it would be nice if dh_makeshlibs could offer a way to forward options to dpkg-gensymbols directly (much like dh_shlibdeps and other wrappers around dpkg-* commands do). > while calling > > dpkg-gensymbols -Pdebian/libgcc1 -plibgcc1 -v1:4.2.2-5 > > keeps the symbol versions from libgcc1.symbols.i386 (attached). Sure, if you give the right version it works. You can pass the -I option as well, it won't change the behaviour. The important bit is the -v option that you need to pass. > Deprecated symbol version seem to be updated as well: That's strange and might be a separate dpkg-gensymbols bug. But you should really strip off #DEPRECATED lines in the symbols file that you maintain. They are generated to ease the long-term maintenance of symbols files within mole but in general they are not useful at all and should be dropped from the symbols files maintained by the maintainer. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
