Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)
Hello, On Mon 21 Aug 2023 at 02:08pm +01, Matthew Vernon wrote: > On 10/08/2023 13:13, Sean Whitton wrote: >> Hello, >> On Wed 09 Aug 2023 at 10:29am +01, Matthew Vernon wrote: >> >>> And you pointed out that, in fact, I'd be better just using >>> dpkg-buildpackage -uc -b >>> >>> In particular, that avoids the need to produce a source package at >>> all, which in many cases is desirable (in a gitish workflow, they're >>> not useful). dgit-user(7) does include runes to produce a >>> source-package-for-sbuild (under "Using sbuild") alongside a note that >>> this source package should not otherwise be used (and a reference to >>> #868527). >> What I like to tell people is that dgit is pretty much only for when >> what you want to do will involve .dscs. No .dscs, no need for dgit. > > I think you mean "dgit build" here? clone/pull/etc are all still very useful > :) No, I mean in those cases too -- those are cases where you have to deal with source packages, because those are what the archive mirrors have. -- Sean Whitton
Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)
Hello, On Wed 09 Aug 2023 at 10:29am +01, Matthew Vernon wrote: > And you pointed out that, in fact, I'd be better just using > dpkg-buildpackage -uc -b > > In particular, that avoids the need to produce a source package at > all, which in many cases is desirable (in a gitish workflow, they're > not useful). dgit-user(7) does include runes to produce a > source-package-for-sbuild (under "Using sbuild") alongside a note that > this source package should not otherwise be used (and a reference to > #868527). What I like to tell people is that dgit is pretty much only for when what you want to do will involve .dscs. No .dscs, no need for dgit. > In fact, while a DD always wants to use some flavour of dgit > build/sbuild/whatever (since a DD will be uploading a source or binary > package), for non-DD-users who don't care about source packages but > just want binaries-from-git, they don't want dgit build at all (since > that will make a source package), but rather dpkg-buildpackage[0]. I think that the above distinction in terms of whether source packages are required is more informative than this distinction. How about something like: As a general rule, you only need to invoke dgit when what you want to do involves generating or unpacking .dsc files. And if you're not actually performing an upload to a Debian-style archive, the only case you need a .dsc is likely to be 'dgit clone'. (I don't think the fact that sbuild's input is a source package is a problem here, but possibly that should be worked in too.) -- Sean Whitton signature.asc Description: PGP signature
Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)
Matthew Vernon writes ("Bug#1043335: dgit-user(7) should note where dgit build
is inappropriate (e.g. CI)"):
> dgit-user(7) should note this prominently.
Also this should probably be mentioned somehow in the `dgit build`
options in dgit(1).
Thanks,
Ian.
--
Ian JacksonThese 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.
Bug#1043335: dgit-user(7) should note where dgit build is inappropriate (e.g. CI)
Package: dgit Version: 10.1 Severity: normal X-Debbugs-Cc: mver...@wikimedia.org, matt...@debian.org Hi, I want to build packages from a dgit tree in CI; I spent some time arranging for e.g. git deborig to work so that I could do: git-deborig mk-build-deps dgit -wg build And you pointed out that, in fact, I'd be better just using dpkg-buildpackage -uc -b In particular, that avoids the need to produce a source package at all, which in many cases is desirable (in a gitish workflow, they're not useful). dgit-user(7) does include runes to produce a source-package-for-sbuild (under "Using sbuild") alongside a note that this source package should not otherwise be used (and a reference to #868527). In fact, while a DD always wants to use some flavour of dgit build/sbuild/whatever (since a DD will be uploading a source or binary package), for non-DD-users who don't care about source packages but just want binaries-from-git, they don't want dgit build at all (since that will make a source package), but rather dpkg-buildpackage[0]. dgit-user(7) should note this prominently. A bonus point might be to refer to dcmd(1), since CI often has requirements about where build artifacts go (in particular, gitlab won't take artifacts from out-of-tree, so build artifacts will need moving from .., which dcmd helps with). In bookworm-and-later dpkg-buildpackage has --changes-file. [this bug report is a summary of an IRC discussion] Thanks, Matthew [0] the result of which may well be a lot of rubbish inside the git working tree, but that is already discussed in dgit-user(7) -- System Information: Debian Release: 11.7 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dgit depends on: ii apt2.2.4 ii ca-certificates20210119 ii coreutils 8.32-4+b1 ii curl 7.74.0-1.3+deb11u7 ii devscripts 2.21.3+deb11u1 ii dpkg-dev 1.20.12 ii dput 1.1.0 ii git [git-core] 1:2.30.2-1+deb11u2 ii git-buildpackage 0.9.22 ii libdpkg-perl 1.20.12 ii libjson-perl 4.03000-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-4+b1 ii libtext-csv-perl 2.00-1 ii libtext-glob-perl 0.11-1 ii libtext-iconv-perl 1.7-7+b1 ii libwww-curl-perl 4.17-7+b1 ii perl [libdigest-sha-perl] 5.32.1-4+deb11u2 Versions of packages dgit recommends: ii distro-info-data 0.51+deb11u3 ii liburi-perl 5.08-1 ii openssh-client [ssh-client] 1:8.4p1-5+deb11u1 Versions of packages dgit suggests: ii cowbuilder 0.89 ii pbuilder0.231 ii sbuild 0.81.2+deb11u1 -- no debconf information
