Re: Our policy around gbp.conf
Hi,
Raphael Hertzog <hertzog@debian.org> 於 2019年12月30日 週一 下午5:28寫道：
>
> Hi,
>
> On Mon, 30 Dec 2019, Samuel Henrique wrote:
> > In the section "Git packaging tool and repository layout", regarding the
> > suggestion to use ~/.gbp.conf, I wish to propose us to have a default
> > debian/gbp.conf in debian/master of all of our packages.
>
> Yeah, we should do that.
I'm curious about the benefit of putting gbp.conf in each package
instead of using
~/.gbp.conf. It's painful to have to update this file once the team
decided to change
the default configuration afterward, and I didn't see any
extraordinary setting that we need.
Apart from that, I'm not sure the status of dep14 [1] (it shows
"draft"), I think it's beneficial
for development across the packaging teams.
[1] https://dep-team.pages.debian.net/deps/dep14/
>
> > B) cleaner = /bin/true
> > For not running dh_clean before the build, I believe this option is just a
> > complexity saver because we run the build on "../build-area/", this means
> > this
> > option is not critical, but we want it.
>
> Yeah, but we don't need it anymore apparently:
> --git-cleaner=CLEAN_CMD
> Use CLEAN_CMD to clean the source tree before the build. The
> default is /bin/true (no cleaning).
>
> > C) [buildpackage] ignore-branch = True
> > I believe this option could be superseded by "[DEFAULT] debian-branch =
> > debian/master" instead, so we can remove the two current ones we have (other
> > one under [dch])
>
> Yes.
>
> > D) [import-orig] filter-pristine-tar = True
> > I don't understand exactly what this does, found this description: "filter
> > out files from tarball passed to pristine tar".
> > What is this filtering? Can somebody give me an example?
>
> It just means that we store in pristine-tar the tarball after it has been
> filtered (and not before).
>
> > E) [import-orig] debian-branch = debian/master
> > Move this one to [DEFAULT], as suggestd in C)
>
> Yes.
>
> > D) [pq] patch-numbers = False
> > I don't use pq yet, and I feel bad for that, but I don't know what this
> > option does
>
> By default the patches generated in debian/patches/ are named like the
> output of "git format-patch", i.e. 0001-Foo.patch, 0002-Bar.patch, etc.
>
> With this option the numbered prefix is dropped and avoids churns when you
> reorder the patch series.
>
> > E) [dch] multimaint-merge = True
> > I don't understand this option.
>
> When you generate the changelog, all entries for each maintainer are
> grouped in a single block instead of having multiple blocks respecting
> the timeline.
>
> By default you have:
>
> [ A ]
> * Change 1
>
> [ B ]
> * Change 2
>
> [ A ]
> * Change 3
>
> With this option you have:
>
> [ A ]
> * Change 1
> * Change 3
>
> [ B ]
> * Change 2
>
> It's really esthetical mainly (and saving a few lines).
>
> > I believe we should agree on which options we want to have as the team' s
> > default and have it on all of our packages (I can do the mass pushing), I
> > assume we will all at least agree on the settings that are fundamental for
> > the packaging to work, like the debian-branch and pristine-tar one, but we can
> > also go a little further and agree on things like "export-dir", "sign-tags" and
> > "cleaner".
> >
> > The first proposal that comes to mind for me, so we have a base to discuss,
> > is the following:
> > ----------------------------------------
> > [DEFAULT]
> > debian-branch = debian/master
> > pristine-tar = True cleaner = /bin/true
> >
> > [buildpackage]
> > sign-tags = True
> > export-dir = ../build-area/
> >
> > [import-orig]
> > filter-pristine-tar = True
> >
> > [pq]
> > patch-numbers = False
> >
> > [dch]
> > multimaint-merge = True
> > ----------------------------------------
> > What are your thoughts?
>
> I would drop "cleaner", "export-dir" and keep the rest. export-dir is
> still a matter of personal preference and might require other changes
> (like DEBRELEASE_DEBS_DIR=../build-area) to fully benefit from it.
>
> > On a side note, I think the option "debian-branch" could support having a
> > variable for the current branch as its value, this way gbp.conf could be
> > easily reusable in a debian/experimental or debian/whatever branch.
>
> What do you mean?
>
> I agree it's painful to have to update this file when you work in other
> branches, hence why I use "ignore-branch" and tend to not hardcode the
> branch in the configuration file..
How about using .git/gbp.conf (per repository)?
SZ
>
> Cheers,
> --
> ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
> ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
>
Reply to: