Hi,
On Sat, Jun 21, 2025 at 01:36:14PM +0100, Ian Jackson wrote:
> 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 <[email protected]> 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?
Works as well but that means you'd have to track any possible changes in
the format - it's not supposed to change much but `gbp-config` would
know about it automatically.
Cheers,
-- Guido
>
> Ian.
>
> --
> Ian Jackson <[email protected]> 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.
>
