Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Am 28.12.2018 um 15:02 schrieb Felipe Sateler:
>
>
> On Fri, Dec 28, 2018 at 10:33 AM Patrick Matthäi  > wrote:
>
> Hola,
>
> Am 24.12.2018 um 12:44 schrieb 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.
>
>
> I dont know how this would help now after the relaxed dependency
> from znc-backlog, because..:
>
> * on changes znc-backlog still needs a binNMU or code changes,
> like now
>
>
> Right. But the current solution is still suboptimal. For example, if
> you upload a new package changing only metadata (say, the Vcs-*
> fields), znc-backlog would need a binNMU. In the more general case, a
> new upstream version of znc might not break the plugin ABI.
>  
>
> * I can provide a znc-plugin-$foobar package, but who ensures at
> an non stable api, if a change is necessary or not? I think it
> will make it more complicated or is there a nice solution for it?
>
> Indeed, this implies a lot more work for you.
>
>
Where a binNMU would be more safe and less work

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#916764: znc-backlog: overly strict dependency on znc?

[Felipe Sateler]

On Fri, Dec 28, 2018 at 10:33 AM Patrick Matthäi 
wrote:

> Hola,
> Am 24.12.2018 um 12:44 schrieb 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.
>
>
> I dont know how this would help now after the relaxed dependency from
> znc-backlog, because..:
>
> * on changes znc-backlog still needs a binNMU or code changes, like now
>

Right. But the current solution is still suboptimal. For example, if you
upload a new package changing only metadata (say, the Vcs-* fields),
znc-backlog would need a binNMU. In the more general case, a new upstream
version of znc might not break the plugin ABI.


> * I can provide a znc-plugin-$foobar package, but who ensures at an non
> stable api, if a change is necessary or not? I think it will make it more
> complicated or is there a nice solution for it?
>
Indeed, this implies a lot more work for you.

-- 

Saludos,
Felipe Sateler

Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Hola,

Am 24.12.2018 um 12:44 schrieb 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.


I dont know how this would help now after the relaxed dependency from
znc-backlog, because..:

* on changes znc-backlog still needs a binNMU or code changes, like now

* I can provide a znc-plugin-$foobar package, but who ensures at an non
stable api, if a change is necessary or not? I think it will make it
more complicated or is there a nice solution for it?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#916764: znc-backlog: overly strict dependency on znc?

[Felipe Sateler]

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  wrote:

> On 2018-12-18 18:13, Felipe Sateler wrote:
> > Hi,
> > On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann 
> 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

Bug#916764: znc-backlog: overly strict dependency on znc?

[Andreas Beckmann]

On 2018-12-18 18:13, Felipe Sateler wrote:
> Hi,
> On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann  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.

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

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


Andreas

Bug#916764: znc-backlog: overly strict dependency on znc?

[Felipe Sateler]

Hi,
On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann  wrote:

> Package: znc-backlog
> Version: 0.20170713-1
> Severity: serious
>

Hmm, not sure this is warranted.


> User: debian...@lists.debian.org
> 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

Bug#916764: znc-backlog: overly strict dependency on znc?

[Andreas Beckmann]

Package: znc-backlog
Version: 0.20170713-1
Severity: serious
User: debian...@lists.debian.org
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}+)


Andreas