"Theodore Tso" <[email protected]> writes: > The features I use of git-buildackage is (a) making sure I'm building > from a valid branch for building debian packages, (b) using > pristine-tar to extract the proper tar.gz file, (c) specifying the > correct options to sbuild for a particular debian branch --- e.g., in > my debian/backports branch, the debian/gbp.conf file contains:
> [DEFAULT] > pristine-tar = True > upstream-tag='v%(version)s' > debian-branch=debian/backports > [buildpackage] > builder = sbuild -A -s -v -d bookworm-backports (b) is useful when using pristine-tar, I agree. It's a little bit annoying to have to remember to run origtargz before building, and git-buildpackage handles that. (c) I think is unnecessary with the default behavior of sbuild? Maybe I'm missing some subtlety, but I have never had to explicitly tell sbuild what chroot to use. It picks one based on the target distribution in the latest entry in debian/changelog (probably indirected through some other file generated from that), so all I have to do is make sure the aliases are set up correctly one time (and when I start building for a new release) and then it works for all packages without any additional configuration. > Well, I started by using "gbp buildpackage", and I have things set up > so that all of the magic options needed by sbuild, et. al, are > automatically specified based on what branch I have checked out what I > am doing. My preference is to avoid needing to type complex commands > like: > dgit sbuild -A -s -v -d bookworm-backports > ... because I will invariablty forget some option, or typo the name of > the schroot, etc. Right, I completely agree. No one is arguing that you should have to remember something like this, just as no one is arguing that you should use patches-unapplied branches. :) I also use patches-unapplied and want the correct sbuild chroot to be autoselected, and I just run "dgit sbuild" and everything works. I'm trying to figure out how to get you to a similar place so that you don't have to think about any of this when you are working on your package. One way to do that would be to stop doing the build with git-buildpackage and just run "dgit sbuild" and let dgit talk to sbuild directly without the git-buildpackage wrapper. I think this may require that you run origtargz before doing a build (and therefore have a *.orig.tar.gz in the parent directory of your current directory, in case that's not where you currently keep them). Another alternative would be to keep using gbp-build but configure dgit so that it knows that you're using patches-applied, which is not the default assumption for gbp-build. There's some, unfortunate for your use case, mixing of defaults between using patches-unapplied and using git-buildpackage since I'm pretty sure nearly everyone using git-buildpackage is using patches-unapplied. The latter option involves the least change to what you're doing now. I think the remaining problem is that changing the *default* dgit --quilt behavior doesn't change the behavior for gbp-build specifically, since gbp-build assumes you're using patches-unapplied and overrides the --quilt default accordingly (as documented in the dgit man page). I think it makes sense for gbp-build to assume patches-unapplied since that is by far the most common case, but maybe it would make sense to have a dgit option that you can add to your .gitconfig or .git/config that overrides that behavior. Maybe this already exists and I just don't know about it? > For me, "gbp buildpackage ; dupload" is simple, and easy. Needing to > type some complex command, such as > dgit --quilt=nofix gbp-build > means that I will forget, because I'm not typing these commands often > enough for them to be finger macros. Right, everyone understands. No one wants you to have to type in more complicated commands. > If the dgit maintainers want to make it easy so that "dgit gbp-build" > always does the right thing --- or even "dgit sbuild" without needing > any magic options added to the comandline, because I can specify the > option that needed depending on whether I'm building for unstable, > backports, or old-backports, via some per-branch config file, great. This part already just works out of the box with sbuild so far as I can tell. Even with git-buildpackage, I suspect specifying this explicitly may be unnecessary (but I don't know for sure since I haven't used git-buildpackage in some time). -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
