Bug#981084: dh-elpa should provide dh-sequence-elpa

[Niels Thykier <niels@thykier.net>]

Starting with David's question (paraphrased beyond recognition): "Will
it break stuff if I add this Provides?"

Nothing will break.  As long as /exactly one/ binary package has that
"Provides" and installing the package will in fact ensure that the
add-on is functional, then everything will be fine.
  And even then, it only starts to break if anyone starts to use the
virtual package (in which case, their package will FTBFS making it
exceptionally difficult for themselves to push that breakage on to you).
 So worst case, you get a minor bug that you did it wrong and it is not
functional after all leaving you with one line of cruft in your
d/control.  All in all, I think you will manage! ;)



Now, on to various claims about why I wrote stuff the way I did.  :)

Mattia Rizzolo:
> On Thu, Jan 28, 2021 at 02:42:14PM +0100, Helmut Grohne wrote:
>> debhelper knows about addons. Traditionally, you could enable them via
>> "--with foo". That turned out to be difficult when you want an addon for
>> for an architecture-independent package (e.g. sphinx) and can skip it
>> for arch-only builds. Therefore a separate way to enable addons was
>> added. When you add dh-sequence-foo to Build-Depends, it'll be enabled.
> 
> I *believe* the driving reason about supporting the new dh-sequence-foo
> notation in Build-Depends(|-arch|-indep) was not that, but mostly about
> DRYing the packaging and reducing the size of d/rules (so as to have a
> more declarative and less imperative packaging).
> 

To be honest, I am not sure what was the driving factor for what any
more, so I cannot say whether you are right or wrong here. :)

However, I do remember that supporting the conditional add-ons was
always going to be via a declarative interface (but that could still go
both ways).


>> This change is a bit of an edge case wrt freeze. Having it in bullseye
>> would be good for one reason: Once someone backports packages that do
>> depend on dh-sequence-elpa, one also has to use a backported dh-elpa
>> unless you add the provides now. So in the interest of simplifying
>> backports to bullseye, I'd say you should include it now.
> 
> Yes, please add such thing.  It's something very small, but the improved
> DRYness is always very nice :)
> 

Agreed, I think it would be safe for bullseye.  Admittedly, I am not a
member of the RT any more, so this holds less weight than it used too. :)

~Niels