Hi all,

Thanks for the bug report and for the thoughful advice.

On 2017-03-10.11:18, Vincent Bernat wrote:
>  ❦ 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).

Yes, I will make the changes suggested by Simon. I won't be able to do
this in the next few days, but will get it done within the next week
after that.

As the libraries are really intended to be private to the quagga
"family" of daemons/utils, I plan to roll them into quagga-core (thanks
for the explanation for how to do this correctly!).

> >
> > 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.
> 

This was also due to me lacking the experience to solve this somewhat
complicated packaging issue. My apologies too.

FYI the version bump originated from this post to the upstream mailing
list[0], which shows upstream's somewhat relaxed attitude to ABI
stability. I guess this is understandable as the libraries are intended
to be private.

> >>  - 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.

Agreed.

[0]
https://lists.quagga.net/pipermail/quagga-dev/2016-December/033087.html

-- 
Regards,
Scott.

Attachment: signature.asc
Description: PGP signature

Reply via email to