Re: RFC: Standardizing source package artifacts build paths

[Guillem Jover <guillem@debian.org>]

On Mon, 2020-03-09 at 09:23:46 -0400, Sam Hartman wrote:
> I'm concerned about a leading . at least for:
> 
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
> 
> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
> So I'd prefer something like debian/build rather than debian/.build for
> at least those directories.
> 
> I don't care as much about substvars, debhelper intermediates, debhelper
> logs and the like.

As mentioned on the proposal the use of a hidden directory is to
reduce clutter (getting the packaged bits alongside the generated
pathnames when listing the debian/ directory contents has always
seemed extremely distracting, which also makes it too easy for them
to end up on a VCS, f.ex.) and to avoid collisions with existing
packaging (due to temporary directory usage or due to staged package
directories).

There's also precedent with hidden directories with debhelper, even
for the staged directories for dbgsyms packages. Making internal stuff
non-hidden would make it more distracting, and if this would mean having
at least two hierarchies (one hidden and one non-hidden), that can be
even more confusing and is more work to cleanup and ignore, which goes
in the opposite direction of simplifying things IMO.

While it's true that we might need to use such pathnames in debian/rules
or debhelper fragment files (which some might consider ugly), IMO that
has always felt like a sign that there's something missing in our
packaging helpers/tools. To me this calls f.ex. for making dpkg-dev and
debhelper support build flavors (for multiple builds) or for debhelper
to automatically look in the relevant build directories when looking up
for files, so in addition to look for them in the installation stage
directory and the source package root directory, it would look there
too, removing the major needs for having to list the full pathnames
explicitly.

Thanks,
Guillem