Hi, Raphael Hertzog <hert...@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 <hert...@debian.org> > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS >