On 2015-12-04 23:38, Michael Biebl wrote: > Hi > > Am 04.12.2015 um 10:06 schrieb Chris Boot: >> Control: severity serious >> >> Hi Michael, >> >> I have now uploaded ppp 2.4.7-1+1 to unstable, therefore the ppp plugin >> this package ships is now broken in sid. Please upload a patched version >> of your package as soon as possible. >> >> I would gladly upload an NMU myself but I cannot easily do so at the >> moment (I am not yet a DD). > > I looked at the resulting package. It has > > Breaks: ppp (>= 2.4.7-2~), ppp (<< 2.4.7-1+~) > > That's overly strict imho. I don't think I want to binNMU/upload NM > every time there is a debian release of ppp. > Could we relax those breaks to > > Breaks: ppp (>= 2.4.8), ppp (<< 2.4.7) > > It's unlikely that the plugin path changes in a Debian revision of ppp?
Hi Michael, The issue is that we may need to break the ABI between upstream releases of ppp, particularly if the upstream release cycle has huge gaps in like there was betwen 2.4.5 (in 2009) and 2.4.6 (in 2014). There is more to the ABI than just the plugin path as I'm sure you're aware. Any patch affecting various structures or functions within pppd itself could cause an ABI change that would break plugins, and I want to avoid that being an issue going forward. I have thought about this, and thus deliberately overload the version number of the ppp package to contain an extra ABI component as well as the normal revision number. See the ppp package's README.source for more details: https://sources.debian.net/src/ppp/2.4.7-1%2B1/debian/README.source/ Essentially, the version I uploaded yesterday is 2.4.7-1+1 and I will only change the ABI revision field if it's absolutely necessary to do so. I will definitely not be making a habit of changing the ABI in regular uploads of ppp. My scheme is admittedly unconventional but it was the neatest way I could think of to achieve my goals. With that all in mind, though, if I do *need* to make such a bump it should just be a matter of a binNMU for all the packages that build ppp plugins, very much like what happens with a soname bump for a shared library. I hope this alleviates your concerns. Regards, Chris -- Chris Boot deb...@bootc.net GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE EEEE
signature.asc
Description: OpenPGP digital signature