Re: Debian glibc symbol version stuff

[Samuel Thibault <sthibault@debian.org>]

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)

> > > I don't really like
> > > libmachuser and libhurduser.  All code using these should instead
> > > explicitly create these as needed and link against its own copies.
> > 
> > Well, that'd be a tedious thing to integrate in all applications which
> > we port to native interfaces of the Hurd.
> 
> Well, I don't think so.  As you're saying, it only concerns packages
> using native interface (which are few), and integrating MIG into their
> build process should be (made) easy.

Integrating anything in a build process is quite often a pain.

> > > > > 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? :)

> > > 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.

> > Debian is a binary distribution.  We can check, but I doubt any Debian
> > binary package uses these symbols, so we can simply drop them entirely.
> 
> ... but only guessing.  (Even if I strongly do believe so.)  But good
> enough for my taste.  But what to do with the problem that on some hosts
> (with older gnumach-dev package, as yours), the xxx_cpu_something RPCs
> will re-appear?  Should we explicitly set versioned build-depends (lower
> and upper bound) for gnumach-dev and hurd-dev when such changes have been
> done, to force the specific versions?

For instance, yes.

Samuel