Re: RFC: Standardizing source package artifacts build paths
FWIW:
We have been using debian packaging from a private repository for the last three years to configure virtual machines.
As a subversion shop, at least, the extraneous files generated by a build aren't an issue because we simply svn-clean after a build. I believe "git clean" does the equivalent operation.
I concur that hiding the build directory with a leading dot is less friendly. It takes a while to understand how package creation / building works, and hiding information from users will make it more difficult.
--
Gerard Weatherby| Application Architect
NMRbox | Department of Molecular Biology and Biophysics | UConn Health
263 Farmington Avenue, Farmington, CT 06030-6406
Phone: 860 679 8484
uchc.edu
________________________________________
From: Sam Hartman <hartmans@debian.org>
Sent: Monday, March 9, 2020 9:23 AM
To: debian-devel@lists.debian.org
Cc: debian-dpkg@lists.debian.org; debhelper@packages.debian.org
Subject: Re: RFC: Standardizing source package artifacts build paths
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***
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.
Reply to: