Discussion:
Bug#916764: znc-backlog: overly strict dependency on znc?
Add Reply
Felipe Sateler
2018-12-18 17:20:01 UTC
Reply
Permalink
Hi,
Package: znc-backlog
Version: 0.20170713-1
Severity: serious
Hmm, not sure this is warranted.
Usertags: piuparts
Hi,
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.

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
--
Saludos,
Felipe Sateler
Felipe Sateler
2018-12-24 11:50:02 UTC
Reply
Permalink
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
Post by Felipe Sateler
Hi,
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
Post by Felipe Sateler
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
Post by Felipe Sateler
ABI is not stable, so backporting an upstream patch could potentially
break
Post by Felipe Sateler
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?
Post by Felipe Sateler
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
Mattia Rizzolo
2019-08-10 10:20:02 UTC
Reply
Permalink
Post by Felipe Sateler
Post by Felipe Sateler
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.
ivodd proposed the other day on #-relase to instead have these type of
plugins embedded in src:znc.

I'm also extremely interested in this as, following on the shoes of
znc-backlog, I've packaged znc-push.

znc-backlog is a single 253 lines file, whereas znc-push is ~2000 lines.
Both change very rarely, so I think it would be feasible to just put
both of them within src:znc's debian/ and build them from there. Then
put them in separate binary packages, with the description explicitly
saying they are contrib modules.
I'll also be happy to help out with the maintenance of these parts if
you'd like to, not to mention provide a full patch.
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Felipe Sateler
2019-08-11 23:30:02 UTC
Reply
Permalink
Post by Felipe Sateler
Post by Felipe Sateler
Post by Felipe Sateler
Perhaps znc could Provide: znc-plugin-$somenumber, which could be
used by
Post by Felipe Sateler
Post by Felipe Sateler
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.
ivodd proposed the other day on #-relase to instead have these type of
plugins embedded in src:znc.
I'm also extremely interested in this as, following on the shoes of
znc-backlog, I've packaged znc-push.
znc-backlog is a single 253 lines file, whereas znc-push is ~2000 lines.
Both change very rarely, so I think it would be feasible to just put
both of them within src:znc's debian/ and build them from there. Then
put them in separate binary packages, with the description explicitly
saying they are contrib modules.
I'll also be happy to help out with the maintenance of these parts if
you'd like to, not to mention provide a full patch.
/me wonders why are we pushing manual work to developers when all it takes
to fix this problem is to automatically rebuild reverse dependencies on new
uploads. Don't we have a solution for this already? How do go or haskell
packages do this?
--
Saludos,
Felipe Sateler
Mattia Rizzolo
2019-08-12 08:50:01 UTC
Reply
Permalink
Post by Felipe Sateler
/me wonders why are we pushing manual work to developers when all it takes
to fix this problem is to automatically rebuild reverse dependencies on new
uploads. Don't we have a solution for this already? How do go or haskell
packages do this?
There is nothing automatic currently.
golang is not rebuilt at all (yes, really), and haskell instead has a
depedency hell where they try hard to upload everything in one go, and
for the remaining a script producing a list of `wb` commands to then
manually issue the binnmus - that's assuming the relevant people notice
they are needed, of course.
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Loading...