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