[Summary]: RFC: Standardizing source package artifacts build paths
Guillem Jover:
> Hi!
>
> We currently have many built artifacts being dropped directly under
> debian/ or under tool specific directories such as debian/.debhelper/.
> These have at least the following problems:
>
> - Make cleaning, an operation that requires executing code from the
> source package itself.
> - Require keeping up updating things like .gitignore or artifacts
> might end up being committed into a VCS.
> - Can stomp over existing files or other tools files, as these are
> generally not namespaced.
> - Clutter the source tree, with debian/ mixing generated and manual
> files.
> - dpkg-dev tools cannot assume the location of the binary package
> to be built, as that depends on the packaging logic and how that
> might drive the various commands.
>
> [...]
>
> Thanks,
> Niels and Guillem
>
Hi,
It seems that the discussion on this topic has stopped and I will now
attempt to summarize the discussion and related consensus as I
understand it.
1) No one seem to have voiced concerns about the general concept of the
proposal - only particular choices for path names and their
default visibility.
2) The primary concern seem to be that the directory debian/.build is
hidden. For some, this was a concern in general, for others the
concern appeared to be that paths they thought useful were being
"hidden by default" (concrete voiced examples include debian/tmp,
debian/<pkg> and upstream build directories).
3) We followed up with an [update to the proposal] were debhelper would
optionally expose some of the relevant directories (some by default,
others on request) with symlinks while still supporting the new
layout. It did not attempt to change the debian/.build directory.
4) There is not been any visible feedback on our updated proposal from
people, who raised concerns about the path, on whether this
alleviated their concern. Nor any visible feedback on the choice of
paths being exposed by default.
*My interpretation of where we are*
>From what I can gather:
* The proposal in concept has consensus.
* Lack of visible feedback on the amendment make it hard to tell if the
amendment alleviates the concern of people wanting certain
directories to remain visible.
The lack of feedback on our amendment can sadly mean anything from
people accepting the amendment, people not being invested in the topic
or even people silently giving up on the discussion - neither documents
consensus in a good way, which is unfortunate as it leaves us in a
stalemate.
*What happens now*
Guillem and I will give another week for follow ups in the hope that
people will provide feedback on the amendment - either that the
amendment alleviates their concern or they would like a different
trade-off on the proposal.
In the absence of any update in the next week, Guillem and I will have
to consider an alternative way of resolving the stalemate. Should that
happen, my personal take would be to apply the "Do'ers decide"-rule from
the constitution and move forward.
Thanks,
~Niels
[update to the proposal]:
https://lists.debian.org/debian-dpkg/2020/04/msg00005.html
Reply to: