Hi! On Tue, 25 Oct 2011 01:04:43 +0200, Samuel Thibault <sthibault@debian.org> wrote: > Thomas Schwinge, le Tue 25 Oct 2011 00:56:24 +0200, a écrit : > > On Tue, 25 Oct 2011 00:37:21 +0200, Samuel Thibault <sthibault@debian.org> wrote: > > > Thomas Schwinge, le Tue 25 Oct 2011 00:31:43 +0200, a écrit : > > > > On Mon, 24 Oct 2011 23:44:27 +0200, Samuel Thibault <sthibault@debian.org> wrote: > > > > > Thomas Schwinge, le Fri 21 Oct 2011 10:27:03 +0200, a écrit : > > > > > > > __dir_unlink@Base 2.11 > > > > > > > __exec_exec@Base 2.11 > > > > > > > + __exec_exec_file_name@Base 2.13-21+ts.0 > > > > > > > > > > Ah, do your changes add some RPCs? Then that part is expected. The > > > > > symbols stuff is precisely meant to catch such changes. > > > > > > > > (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't > > > > stop due to this, as I understand its documentation?) > > > > > > I don't think it does. > > > > Hmm, should it do so? Or are you manually watching the glibc build > > process for such changes, or how does this work? (Or how should it > > work?) > > IIRC the idea is that new symbols are not a problem. Adding them can be > overlooked, that'll just produce dependencies which could be less tight > (by expressing when exactly the symbols were introduced) OK, I see. Not ideal, but good enough, yes. > > > > > > Now, the question is whether the RPC user stubs should get Debian symbol > > > > > > versioning at all, or if they're simply a best-effort thing? > > > > > > > > > > Making them a best-effort would mean that some programs using them would > > > > > get broken when they are removed. We don't really want that :) > > > > > > > > Then we really have to revert dd48e23f43730038df4bb191e7acc47a4ab73c69? > > > > > > Why? > > > > (To restore the symbols.) > > Again, why? :) This is one solution to the problem, but both of us don't prefer it, as there is a better one: > > > > But I really hope (and expect) that nobody has been using these functions > > > > anymore (with their bogus names), for years already. > > > > > > Then that's fine. > > > > ... but only guessing. (Even if I strongly do believe so.) > > Then let's just check and be done with guesswork. I did not know there was a straightforward/standardized way for doing this. How does this work? Is there a tool to examine each packages' ELF objects for certain undefined symbols? Grüße, Thomas
Attachment:
pgpKzx9l7aMWF.pgp
Description: PGP signature