On Wed, Oct 21, 2015 at 01:43:26PM +0100, James Cowgill wrote:
> Hi,
>
> On Tue, 2015-10-20 at 19:37 +0200, Florian Weimer wrote:
> > * James Cowgill:
> [...]
> > > One thing which was suggested was to use 1.3.14 and then disable at
> > > compile time all the new features which may affect the ABI and then
> > > revert the SONAME change, but is doing that actually allowed for the
> > > security archive or will the update be too big?
> >
> > We can do that, but I don't know if it is a good idea to patch
> > cryptographic software in such extensive ways.
> >
> > We can live with the addition of new symbols, but removal of symbols,
> > changes in struct sizes or offsets, and so on, would be hugely
> > problematic. For are start, you could just build both the old and new
> > versions and run libabigail on them, to get an idea what actually did
> > change.
>
> So I checked the ABI and had to revert a few commits. I've attached the
> original libabigail diff (all against upstream versions) and the diff
> after my patches. The variables don't look to me like they were ever
> intended to be part of the public ABI so I don't think they're that
> important.
Could you test that the reverse build deps in jessie still build?
If so, I'd be fine with that approach for jessie.
For wheezy we can probably only make it end-of-life? There's
only two reverse deps (pdns and gatling).
Cheers,
Moritz
