Re: Dependencies on shared libs, news and difference between archs
Hi,
On Fri, 31 Aug 2007, Guillem Jover wrote:
> On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote:
> > I think my work is mostly ready for unstable as it is. The last step is to
> > convince Guillem Jover, the main dpkg maintainer, to merge that in the
> > master branch. He believes that supporting odd cases encourages bad
> > practice on library management. I don't think so. On the contrary I'd like
> > to promote sane library management and I made some efforts in the included
> > documentation to promote that.
>
> First, thanks for your work on this!
>
> For libraries with versioned symbols, just checking for the needed
> version nodes should be enough, and I'd say that adding symbols to
> a previously existing version node or breaking their ABI is broken,
> and something that we should not tolerate.
We could try to change dpkg-gensymbols to be smarter about this. If it
detects that the library is using versioned symbols (i.e. version is
different from "Base"), then we tolerate less.
But it's not as easy as it seems. For example glibc uses GLIBC_PRIVATE
versioned symbols which can change as they are internal between
various glibc related objects but they are not meant to be used by
others. (this did happen betwen etch's glibc and the current one)
On the other hand, not merging the code also means continuing to
tolerate even more problems, so my work is not a regression at all.
> But for libraries w/o versioned symbols your solution is the most
> reasonable, for now libs with versioned symbols could use it as
> well and we can add a different mode for version-node-only support
> afterwards.
Indeed, but I'm not sure that such a mode is really needed (except maybe
for C++ versioned libraries if that exists where it might avoid having to
handle arch-specific symbol files for very little gain). I'd rather
continue to have the full symbol information available and make our tools
check more rigorously in those cases where we know that we should expect
more.
> So let's start the merging process anyway, I'll try to review the
> branch in the next days, although Frank has been tracking this, I'm
> not sure if he did a final review.
Frank didn't review the changes made after the introduction of the manual
pages (after 2007-07-16).
Any chance this can be included in your monday upload? Or at least, that
we merge it directly after and make an experimental upload so that we can
start working a bit further in the integration with debhelper for example.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: