Marc Haber writes ("Re: Bug#1128520: please implement dgit.default.tarball-dir
[and 1 more messages]"):
> On Sat, Feb 21, 2026 at 09:57:44PM +0000, Ian Jackson wrote:
> >Sadly git-deborig and origtargz don't use it.
>
> Are there bug reports requesting that?
I don't know. I thought I had filed at least one such *somewhere* but
I can't seem to find it. I looked in the archived bugs for
git-deborig in devscripts (where it was for a lot of its life), too.
I found this
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848816
which is kind of related and mentions a possible -devel conversation.
> >In fact dgit is running dpkg-source in a secret hidden working area it
> >creates inside your .git directory. I don't think there is any way to
> >improve this output from dpkg-source.
>
> "Changing work directory to ..."
dgit changes working directory a *lot*. Maybe we could have it print
the working directory explicitly before running important dpkg-source
commands, or other commands that have a tendency to print relative
pathnames.
> >I think it's a shame that gbp doesn't read git-buildpackage.whatever
> >things from git config.
>
> Somebody should write a tool to generate .gbp.conf from git config.
Oooh! Very good idea! Are you volunteering? :-)
> >We could institute a Debian-wide default for orig tarballs by putting
> >it in devscripts and making the tools there honour it. It would want
> >some negotiation with the gbp maintainers but it doesn't seem
> >impossible.
>
> That's what I would try to do (in the scope of my limited
> possibilities). Having dgit walk ahead would make that considerably
> easier.
devscripts doesn't have config, and the user may not be using git, so
the devscripts thing would need to be an env var.
How about DEBIAN_ORIG_TARBALLS_DIR ? It doesn't need to be short.
devscripts usually has a relatively relaxed maintenance approach so I
doubt we'd get any serious pushback, if we do it in devscripts first.
That would give folks a chance to bikeshed the env var name.
Also the implementation in dgit is nontrivial.
To be clear I think the semantics of DEBIAN_ORIG_TARBALLS_DIR ought to
be: programs that just process orig tarballs (like git-deborig and
origtargz) should *create* any *only* there. They might look for them
only there, or in .. .
dgit looks for origs in .. as well as the bpd, and copies them into
the bpd if it finds them in .., to work around the lack of dir support
in git-deborig and origtargz. Should it do the same with
DEBIAN_ORIG_TARBALLS_DIR: that is, if it finds a .orig in .., should
it copy it to the tarballs dir ?
Programs that generate .dscs still need to put the origs next to the
.dsc, which means that origs now might end up in more places.
Specifically, they would end up in the bpd *and* in
DEBIAN_ORIG_TARBALLS_DIR. Should we use hardlinks or something or
does everyone already just expect them to be copied about?
(How do other tools that invoke dpkg-source cope with the fact that
dnpkg-source insists on expecting origs next to the .dsc .. ?)
> >Personally I wouldn't object to such a scheme in principle but I am
> >already foreseeing difficulties with it: for example, dgit
> >doesn't always *know* what the architecture is.
>
> I'd basically go with the distinction between "source" and "not source"
> builds. It's a pain that doing a binary buildpackage (for example, to
> run Lintian) over an already built source package will render the source
> package unuploadable since the .dsc gets overwritten.
Hmm, yes. I still think this is a more complicated quesstion.
Ian.
--
Ian Jackson <[email protected]> These 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.
