[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Summary]: RFC: Standardizing source package artifacts build paths



Short version: tools that don’t create hidden directories are friendlier to newbies, but it’s not that big a deal.

--

I haven’t further advocated my earlier “no hidden directories by default” position because it strikes me as peevish to be fussing about a well designed tool that I benefit from tremendously while contributing essentially nothing.

When I first started using dpkg-buildpackage while barely understanding much about how to configures packages I wasn’t aware that hidden directories where being generated until I went to add my code to subversion. Optionally exposing the directories doesn’t address this; once I knew hidden directories were created/used it became a non-issue.

Since the consensus seemed to be the default behavior of creating hidden directories wasn’t a general concern, I didn’t see any particular reason to follow up or object to the current proposal.

-- 
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 

On May 2, 2020, at 10:19 AM, Niels Thykier <niels@thykier.net> wrote:

*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

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://urldefense.com/v3/__https://lists.debian.org/debian-dpkg/2020/04/msg00005.html__;!!N0rdg9Wr!8uP4CWiSzA15-853SjU36hM22XtvUd7HSiNOVIIC1FCuxJKECAtTzXUzKJFV361xyXo$



Reply to: