On Fri, 10 Mar 2017 at 07:53:11 +0100, Vincent Bernat wrote: > I suppose that's why I am in copy (the other actions are pretty obvious > and I suppose Scott will apply them soon; I can also do that if he's > unavailable).
The other reason I wanted to Cc you is because as sponsor, you were responsible for checking that the package split proposed by the maintainer was Policy-compliant. I would have expected a sponsor to query the current library packaging and not upload without changes, because as it stands at the moment, it isn't correct for either private/internal libraries or public libraries; it's somewhere in between. (In particular, seeing the Lintian overrides in the diff should probably have been a warning sign.) > Acting like it is a > "0" versioning in the packaging shows there is no real guarantee in > that and is less invasive than patching the source. No, acting like it is a "0" version is saying that this library is fully compatible with all previous versions of libquagga0. This is clearly not true: anything with a DT_NEEDED entry for libzebra.so.0 would now fail to load, because there is no longer a libzebra.so.0 in the package. There is nothing special about .so.0 from a stability point of view: users of libglib2.0-0, libasyncns0, libbsd0, etc. presumably expect them to behave like correct public shared libraries. If a library offers development files and is placed on the default search path for the linker, then its maintainer is effectively saying it is a normal public shared library and will be managed accordingly, including package renames, ABI transitions and going through the NEW queue if it becomes necessary. If that isn't the intention, then the library shouldn't be on the default search path. > - removing libquagga0 and libquagga-dev and put the libraries in > quagga-core and in /usr/lib/quagga. Not shipping the development > files. This is a change that would likely to be accepted by the > release team. I would recommend this route. As you say, splitting libquagga0 into 5 library packages seems like overkill if nobody is going to use it. If it is going to be treated as a public shared library in a future version, at that point you will have no choice but to split it (at least the parts whose SONAMES end with a nonzero version, but it would be safer to do the full split). But it sounds as though that is more appropriate for the future, or perhaps never, than for stretch. > But maybe the reporter of #705306 would find that not > helpful (it's unclear if he is a user of the actual libquagga-dev or > if he was just asking from a policy point of view). The reporter of #705306 seems to have been primarily objecting to the fact that quagga contained static libraries and headers from a waste-of-space point of view (this was before the -dev was split out at all). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705306#17 suggests that those libraries are considered experimental (although that might have changed since 2013), and I didn't see anyone commenting on that bug giving any indication that they would want to use any of the libraries from outside src:quagga. S
