Control: clone -1 -2 Control: reopen -2 Control: reassign -2 znc Control: affects -2 znc-backlog Control: retitle -2 znc: please provide a znc-plugin-$version that external plugins can depend on
On Tue, Dec 18, 2018 at 3:39 PM Andreas Beckmann <a...@debian.org> wrote: > On 2018-12-18 18:13, Felipe Sateler wrote: > > Hi, > > On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann <a...@debian.org> > wrote: > > > >> Package: znc-backlog > >> Version: 0.20170713-1 > >> Severity: serious > >> > > > > Hmm, not sure this is warranted. > > It's currently uninstallable in sid. > Instead of requesting a binNMU (and doing so everytime znc changes), I > asked this question here. > Well, just like libraries need transitions, applications having plugin APIs need transitions too. Anyway, I've relaxed the dependency as advised by https://wiki.debian.org/binNMU > >> do you really need a dependency on the exact binary version of znc > >> available at the build time of znc-backlog? I.e., every time znc > >> gets uploaded *or binNMUed*, a binNMU of znc-backlog is needed, too. > >> Wouldn't a dependency computed from the upstream version be sufficient? > >> E.g. znc (>= ${znc:upstreamversion}), znc (<< ${znc:upstreamversion}+) > >> > >> > > I'm using the same as the znc plugins shipped by znc itself. AFAIK, the > znc > > ABI is not stable, so backporting an upstream patch could potentially > break > > other plugins. > > But that's unlikely to happen on binNMUs, isn't it? > If znc needs rebuilding, the plugins might need too, wouldn't they? > > Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by > > out-of-tree plugins? Adding the znc maintainers to the loop for their > input > > That's being used successfully by some packages ... > I'm creating a new bug for tracking this (better) solution. -- Saludos, Felipe Sateler
