❦ 10 mars 2017 09:29 GMT, Simon McVittie <s...@debian.org> : >> 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.)
During the first upload, the packaging was policy compliant as all
libraries were sharing the same version. There was no override. The
change in SO name for libzebra was done during a minor version
update. At this time, I suggested to solve the problem by ignoring
lintian instead of being overly complicated for a library without
reverse dependencies. My bad.
>> 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.
That's the technical side. 0 can also mean that upstream doesn't
care about versioning (because that's also the default value).
> 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.
OK with that.
--
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
