Re: Reintroducing src:toxiproxy for its -dev package
On 24 November 2022 7:34:58 am IST, Mathias Gibbens <gibmat@debian.org> wrote:
> I've been working on updating/packaging several golang packages (plus
>their own dependencies) that will be needed by new feature releases of
>LXD. I'm trying to keep ahead of the large changes in LXD's dependency
>tree so eventually when the 6.0 LTS lands (still quite a while out) it
>will be trivial to update the package in Debian.
>
> One rabbit hole I've wandered down is needing to update golang-
>github-shopify-sarama, which has a dependency on
>github.com/Shopify/toxiproxy. That used to be packaged as toxiproxy,
>but was RM'ed in bug #940453. I'd like to reintroduce the -dev package
>as a build dependency, but am not too keen on reintroducing an actual
>binary package shipping the `toxiproxy` command (and its related
>service files, etc).
>
> Would there be any objections to me filing an ITP to reintroduce
>src:toxiproxy that would only build bin:toxiproxy-dev, and (at least
>for the time being) not building bin:toxyproxy or bin:toxyproxy-cli? Or
>maybe there would be a better way to handle this -- I'm open to any
>other suggestions.
I remember hearing it from Shengjing sometime that we only need a subset of code from some packages, but
then, we end up packaging everything in the corresponding B-D and end up with a monster package (which I tend to agree with).
If building all binary packages and maintaining them is a lot of work for you, it makes sense to just get the lib one (-dev) in. You can enable building rest of the binaries if someone actually needs them at some point.
That'd be another trip to NEW, but probably still worth the effort.
Another option could be to vendor parts of code you need in lxd but this is not elegant.
--
Best,
Nilesh
Reply to: