On Thu, Nov 24, 2022 at 08:11:19AM +0530, Nilesh Patra wrote: > > On 24 November 2022 7:34:58 am IST, Mathias Gibbens <[email protected]> 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).
toxiproxy doesn't seem to be a monster. It only has 6 dependencies. https://github.com/Shopify/toxiproxy/blob/master/go.mod No objections, but could you use the new convention for the -dev package, which should be golang-github-shopify-toxiproxy-dev. When you reintroduce some packages, there's no need to keep the old name. It's just like packaging new package.
