On Tue, Oct 14, 2014 at 10:14:08AM -0400, Michael Terry wrote:
> Another option would be to call "dh_makeshlibs -V" with no version
> argument. This is a conservative option, so the reverse depends will be
> tightly coupled. But it's safe.
That doesn't address the purpose of symbols files, which is to guard against
buggy changes to the library ABI on package update. Whether it's from a
careless upstream, a toolchain breakage, or an ill-fated Debian/Ubuntu
patch, if a library's public ABI changes, we want to catch this; and without
symbols files, we don't.
> On Fri, Oct 10, 2014 at 9:57 AM, Bjoern Michaelsen <
> bjoern.michaelsen@canonical.com> wrote:
>
> > so liborcus now build-depends on libixion due to an update that was
> > synced to utopic. I cleared most of the work needed for a MIR[1], but
> > will not yet add a symbols file, as a quick check shows it would include
> > (non-template) symbols from the ::std:: and ::boost:: namespaces which
> > clearly it shouldnt. So as per
> > https://wiki.debian.org/UsingSymbolsFiles: "If you find (on some arches)
> > symbols that are exported which are not supposed to be public, you must
> > not use symbols versioning at all." Before shipping a symbols file,
> > upstream would need to get its ducks in a row.
I have no idea what the recommendation on that wiki page is supposed to
mean. "Symbol versioning" is something entirely different from symbols
files, anyway. That page has AFAICS had zero peer review in Debian
regarding its contents.
There are some practical problems regarding symbols files for C++ libraries,
which make it debatable whether these are actually a good idea in the
current implementation. I don't know whether the MIR team wants to grant a
variance for this library as a result. However, I don't see how the
imported (weak) std:: and boost:: symbols should be a blocker for creating a
symbols file. Just filter those out of the symbols file, and be careful to
use DPKG_GENSYMBOLS_CHECK_LEVEL=1, not =2.
> > Note in addition, that:
> > - currently the only possible client of libixion is LibreOffice
> > - the libixion ABI so far does not have any ambition to be stable yet --
> > in fact, IIRC the ABI changed with every release so far
Has the *soname* changed with every release? It's fine to say that the ABI
is not stable yet. Symbols files are not about preventing ABI changes,
they're about preventing ABI *breakages* to ensure that any ABI changes are
done in an orderly fashion.
> > So for now, Id suggest to either:
> > a/ keep LibreOffice on its internal build versions of libixion/liborcus
> > and not update the packages in the archive (which are unused anyway)
> > b/ update libixion/liborcus without a symbols file for now, use that from
> > LibreOffice and be optimistically confident that upstream libixion
> > will fix their exports by the time there are actually other clients
> > than LibreOffice for the lib (if that should ever happen).
As this is already an embedded code copy today and there are no other
reverse-dependencies, I don't think it's a problem to continue this way
through 14.10. Ideally we wouldn't have libixion in the 14.10 archive at
all then, if we're arguing that nothing else should be using it; but that's
not critical.
But I am not convinced this is actually a matter for libixion upstream to
fix. I remember (but cannot currently find references to) discussions about
the fact that g++ needs to output these weak symbols for destructors etc.,
and that it's not possible to mask them in the exported ABI without adverse
consequences. I think you'll want a plan for this MIR that doesn't rely on
these weak symbols going away.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
