Re: RFC: Standardizing source package artifacts build paths
Sam Hartman:
> 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.
>
Hi,
Guillem and I have debated this and come to a solution, which we believe
will be able to address the concerns about the path being "hidden". It
also enables us to simplify parts of the migration in some cases.
The short version of that solution is to enable debhelper to expose the
relevant directories where you want it and under debian/.build at the
same time (the latter being a symlink to the former)[1].
This can be made to cover the directories you mention above, but also
e.g. the build directory for upstream builds, which was mentioned
elsewhere in this thread.
Based on the feedback so far, I will go with the following defaults in
debhelper:
* build directories are exposed if -B/--builddirectory is used to
request it. If there is no explicit -B/--builddirectory, it will
(in a new compat level) be hidden by default.
* The staging directories a la d/tmp will be exposed if --destdir is
used with dh_auto_install.
- I will expose d/tmp by default for now but "parallel" d/tmp-X dirs
are not (they currently require a --destdir to work as it is now).
* d/<pkg> are exposed by default for now.
Any other debhelper artifact will move to a new path in a future compat
level (at this stage, we are talking debhelper/14 rather than debhelper/13).
~Niels
[1] Note that dpkg will migrate to always use the paths under
debian/.build. This should not matter in practise unless you fiddle
with the symlinks that debhelper creates.
Reply to: