Guido Günther writes ("Re: breaking gbp-config out into a separate binary
package"):
> On Fri, Jun 20, 2025 at 03:37:43PM +0100, Sean Whitton wrote:
> > What do you think about breaking gbp-config out into its own binary
> > package?
>
> That would work form me (and we've had other situations where that would
> be useful in the past). `gbp config` (as all other subcommands) depends
> on classes from the `gbp` module so we'd need to split out the minimal
> subset there too to get a smaller set of dependencies (we do something
> similar for the git-buildpackage-rpm to not have `git-buildpackage`
> depend on rpm tooling). A simple autopkg test would make sure that we
> don't break this on refactors.
Cool. That sounds promising. I think that would enable us to make
the improvements we want.
I just wanted to share with you an alternative suggestion we received:
Marco d'Itri writes ("Re: Bug#1105759: git-debpush upstream tag confusion"):
> On Jun 20, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote:
> > This might involve a dependency on [gbp-config]
>
> Agreed. But gpb.conf is a simple ini-style file, and there are
> plenty of Perl modules which can parse them so it may be simple
> enough to just reimplement this part.
I guess you think it would be better for us to Depend on a split-out
gbp-config, than to reimplement the parsing using some INI file
reader (in a Perl library maybe).
So, I think you would recommend against that alternative
reimplementation approach. Am I right about that?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
