Hi, (sorry for the late response, I acquired a bit of backlog due to a hardware failure and are only slowly catching up) On Sat, Oct 25, 2014 at 12:44:06PM +0200, Niels Thykier wrote: > That said, feel free to do what you can without the ABI breakage. If > some of your rdeps can be (partly) enhanced with a simple rebuild > against the new version of (API+ABI compatible) APT, I am also more than > happy to schedule binNMUs for them. Challenge accepted. ;) In fact, I tried earlier this week how bad it would be if we pull every trick possible to get it "compatible" and it surprisingly ends up working for most stuff (just tried with apt-* and aptitude for a bit). Now, I said "compatible" for a reason though: Overloading a previously not overloaded method is ABI compatible, but an API break as function references aren't unambiguous anymore, so while stuff still runs, a recompile would fail. Easy to detect & fix and I have never seen in it in practice (we and other libraries do this kinda regular). Another thing is: To not make it more dirty than needed I marked quiet a few symbols as hidden which should have never been exported. Obvious API break, but again in practice, nobody should be using them up to the point that I would consider it bug if they do. Its more a problem of how "dirty" I want the code to be, in the end I could relatively easy keep them exported as well, I just don't see the point as it has practically only disadvantages. Both can be easily detected with a rebuild of the direct r-dependencies, which I will do to confirm that it is really not a problem in practice and to figure out which ones need a binNMU (= I changed some inlines [and made them non-inline] which degrade properly, so its okay in theory, but as one of them is security related more is better. It couldn't hurt to rebuild all though just to be sure). I meant to have done that already, but as I am running late lets just assume I already did and everything works and discuss it "in parallel". On a completely unrelated note an early warning: #766758 might need input from the release team and/or a bunch of unblocks for the involved packages (leaving undefined for now which would be involved or the solution itself) > > P.S.: Just to underline how serious I am about that: if it helps > > our cause I would even be willing to sign the "secret supplementary > > protocol" 'people' suggested earlier this month in #d-apt … > > > > [...] > > Not familiar with said "secret supplementary protocol" and have not been > able to find it in the backlog. It wouldn't be secret if it could be easily found. In the end, it might just be an euphemism for "a release assistant tried to blackmail me, so I thought it is just to return the favor". ;) Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature