Hello, On Fri 04 Jun 2021 at 06:39PM +02, Helmut Grohne wrote:
> Hi Sean, > > On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote: >> dgit wraps some of the existing tools. While dgit is mainly for humans, >> one role it can have in automated toolchains is producing an ephemeral >> source package for the purpose of performing a build where the real >> input is a git tree. dgit knows how to convert various forms of git >> tree into source packages and there are TODOs for some others. > > While dgit does wrap build tools and thus could be a possible mdbp user, > dgit does so in a way that forwards the flexibility of those build tools > through dgit. As such, it has a subcommand for each implementation and > lets the user fiddle with the underlying implementation in the way they > want without providing any kind of abstraction. I'm vaguely convinced > that for dgit, this is best. An abstraction could be added as another > subcommand if desired, but does buy little in the end. After all, dgit > users tend to want tight control over the build and know their favourite > build tool well. > > The intended audience for the abstraction on the other hand would be > performing many builds in a mechanical way. Right. I was thinking that if you wanted to perform many builds from git trees, dgit could help obtain the .dscs. -- Sean Whitton
signature.asc
Description: PGP signature
