Bug#981084: dh-elpa should provide dh-sequence-elpa
control: tag -1 + pending Hello, On Mon 25 Jan 2021 at 06:13PM +01, Helmut Grohne wrote: > Package: dh-elpa > Version: 2.0.6 > Tags: patch > > Please provide dh-sequence-elpa. Doing so allows using it declaratively. > Instead of adding "--with elpa" to the dh invocation, one can then add > dh-sequence-elpa to Build-Depends. Using the dependency technique, use > of the addon can be restricted to indep-only builds by moving it to > Build-Depends-Indep. Also the sequence can be conditionalized using > build profiles. (Though using build profiles requires fixing #981014.) Someone already sent in a salsa merge request for this a week or so ago and I applied their patch. -- Sean Whitton signature.asc Description: PGP signature
Bug#981084: dh-elpa should provide dh-sequence-elpa
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
Bug#981084: dh-elpa should provide dh-sequence-elpa
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). In fact, it isn't _that_ hard to run `dh --with foo` only in some situations and not others, some `if` will be enough to take care of this. > 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 :) -- 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 `- signature.asc Description: PGP signature
Bug#981084: dh-elpa should provide dh-sequence-elpa
Hi David, On Thu, Jan 28, 2021 at 09:06:59AM -0400, David Bremner wrote: > I haven't really undestood the implications of this yet. Are you > proposing this change for bullseye, or can it wait until after the > freeze? This is not obvious. Let me give more details, so you can get a better picture. 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. Given that presently nothing provides dh-sequence-elpa, nothing can practically use it. Adding the provides changes nothing right now. That is until someone else starts depending on it. Therefore, I think the risk of regressing anything is quite low. 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. Does that make sense to you? I'm Ccing Niels, so he can correct the things that are wrong if any. Helmut
Bug#981084: dh-elpa should provide dh-sequence-elpa
Helmut Grohne writes:
> --- a/debian/control
> +++ b/debian/control
> @@ -27,6 +27,7 @@
> libtext-glob-perl,
> ${misc:Depends},
> ${perl:Depends},
> +Provides: dh-sequence-elpa
> Description: Debian helper tools for packaging emacs lisp extensions
> This package provides a helper for packaging emacs lisp extensions
> in a way compatible with the GNU Emacs 'elpa' package repository.
>
Hi Helmut;
I haven't really undestood the implications of this yet. Are you
proposing this change for bullseye, or can it wait until after the
freeze?
d
Bug#981084: dh-elpa should provide dh-sequence-elpa
Package: dh-elpa
Version: 2.0.6
Tags: patch
Please provide dh-sequence-elpa. Doing so allows using it declaratively.
Instead of adding "--with elpa" to the dh invocation, one can then add
dh-sequence-elpa to Build-Depends. Using the dependency technique, use
of the addon can be restricted to indep-only builds by moving it to
Build-Depends-Indep. Also the sequence can be conditionalized using
build profiles. (Though using build profiles requires fixing #981014.)
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,7 @@
libtext-glob-perl,
${misc:Depends},
${perl:Depends},
+Provides: dh-sequence-elpa
Description: Debian helper tools for packaging emacs lisp extensions
This package provides a helper for packaging emacs lisp extensions
in a way compatible with the GNU Emacs 'elpa' package repository.
Helmut
