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

2020-05-06 Thread Calum McConnell
> > > I kinda like the idea of prefixing *all* temporary directory with
> > > a '_'
> > Completely reasonable and almost auto-explaining, I'd say. +1 for
> > Michael's suggestion.
> 
> What about placing temporaries below debian/build/? Anything where
> names
> aren't fixed in Policy, i.e. which could be renamed with an
> underscore at
> the beginning, could also be moved.

I agree with the idea of prefixing build and other temporary
directories with an underscore, but I don't think we should move all
files that aren't explicitly defined in policy to be under
debian/build.  For instance, the git-buildpackage configurations aren't
fixed in policy, but they definitely shouldn't go in a build directory.

Additionally, I think it is sometimes useful to have multiple temporary
directories.  Some teams might use a cache folder: and if all
temporaries had to be under debian/build/, then they'd likely need to
put their caches there, moving their actual build folder to
debian/build/build/.  Which is all well and good, but then you get
packages who create a debian/build/ folder containing just one
subfolder named build/, and so on and so forth. The point is that I
think there is a real benefit to saying "Okay, put all your temporary
directories under the debian/ folder, and prefix their names with an
underscore".  Clean operations are still simple: but teams have
flexibility in how they run their builds.


signature.asc
Description: This is a digitally signed message part


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

2020-05-05 Thread Simon Richter
Hi,

> > If you want to avoid name collisions, you could also use
> > debian/_build

> > I kinda like the idea of prefixing *all* temporary directory with a '_'

> Completely reasonable and almost auto-explaining, I'd say. +1 for
> Michael's suggestion.

What about placing temporaries below debian/build/? Anything where names
aren't fixed in Policy, i.e. which could be renamed with an underscore at
the beginning, could also be moved.

   Simon



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

2020-05-05 Thread Gunnar Wolf
Michael Biebl dijo [Mon, May 04, 2020 at 11:51:05AM +0200]:
> >> Personally, I don't see any real benefit of standardizing on (making up an 
> >> example here) debian/.build over debian/build.
> > 
> > Same here. The arguments against debian/build are very weak. If we care
> > about a source package building a binary package named "build" or
> > whatever, it's really a unique case and surely it can be built with
> > some overrides and passing a different path where needed.
> 
> If you want to avoid name collisions, you could also use
> debian/_build
> 
> I kinda like the idea of prefixing *all* temporary directory with a '_'

Completely reasonable and almost auto-explaining, I'd say. +1 for
Michael's suggestion.


signature.asc
Description: PGP signature


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

2020-05-04 Thread Michael Biebl
Am 04.05.20 um 09:55 schrieb Raphael Hertzog:
> On Sat, 02 May 2020, Scott Kitterman wrote:
>> Personally, I don't see any real benefit of standardizing on (making up an 
>> example here) debian/.build over debian/build.
> 
> Same here. The arguments against debian/build are very weak. If we care
> about a source package building a binary package named "build" or
> whatever, it's really a unique case and surely it can be built with
> some overrides and passing a different path where needed.

If you want to avoid name collisions, you could also use
debian/_build

I kinda like the idea of prefixing *all* temporary directory with a '_'





signature.asc
Description: OpenPGP digital signature


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

2020-05-04 Thread Raphael Hertzog
On Sat, 02 May 2020, Scott Kitterman wrote:
> Personally, I don't see any real benefit of standardizing on (making up an 
> example here) debian/.build over debian/build.

Same here. The arguments against debian/build are very weak. If we care
about a source package building a binary package named "build" or
whatever, it's really a unique case and surely it can be built with
some overrides and passing a different path where needed.

There's also the precedence of debian/source that has taken over a part of
the namespace below the debian directory.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature


Re: +1 (no hidden directory, please) Re: [Summary]: RFC: Standardizing source package artifacts build paths

2020-05-03 Thread Richard Laager
On 5/3/20 5:54 PM, Holger Levsen wrote:
> On Sun, May 03, 2020 at 10:56:32PM +0200, Simon Richter wrote:
>> Frankly, I don't see the point in hiding the directory. The only person
>> who'd ever look into that directory would be someone inspecting what
>> happened during a build process, and all that hiding directories
>> achieves is adding more mental load to them where they have to remember
>> to use ls -a, and type a dot before trying to tab-complete anything.
>>
>> Basically, it would just be annoying with no good reason.
> 
> my thoughts exactly.

Agreed. Nothing else in the debian directory is hidden. I think the
burden should be on justifying why this should be the one hidden directory.

-- 
Richard



signature.asc
Description: OpenPGP digital signature


+1 (no hidden directory, please) Re: [Summary]: RFC: Standardizing source package artifacts build paths

2020-05-03 Thread Holger Levsen
On Sun, May 03, 2020 at 10:56:32PM +0200, Simon Richter wrote:
> Frankly, I don't see the point in hiding the directory. The only person
> who'd ever look into that directory would be someone inspecting what
> happened during a build process, and all that hiding directories
> achieves is adding more mental load to them where they have to remember
> to use ls -a, and type a dot before trying to tab-complete anything.
> 
> Basically, it would just be annoying with no good reason.

my thoughts exactly.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


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

2020-05-03 Thread Simon Richter
Hi,

On 02.05.20 17:53, Andreas Metzler wrote:

> I do think it is a splendid idea to separate generated stuff from
> everything else, I think there is no real good reason for using a
> hidden toplevel directory.

Frankly, I don't see the point in hiding the directory. The only person
who'd ever look into that directory would be someone inspecting what
happened during a build process, and all that hiding directories
achieves is adding more mental load to them where they have to remember
to use ls -a, and type a dot before trying to tab-complete anything.

Basically, it would just be annoying with no good reason.

I could see some potential in a debian/build/ directory, and moving
everything that is generated under it, but that would first have to be
implemented in debhelper, then we could start moving non-debhelper
packages over, and only then it could be turned into policy.

   Simon



signature.asc
Description: OpenPGP digital signature


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

2020-05-02 Thread Scott Kitterman
On Saturday, May 2, 2020 11:53:26 AM EDT Andreas Metzler wrote:
> In gmane.linux.debian.devel.general Niels Thykier  wrote:
> [...]
> 
> >  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.
> 
> [...]
> 
> FWIW I did not followup there because symlimking a hidden directory
> just complicates things without addressing arguments against using a
> hidden directory at all. I have not received a real answer to
> 20200331172540.ga1...@argenau.bebt.de. - But please bear with me ...
> 
> I do think it is a splendid idea to separate generated stuff from
> everything else, I think there is no real good reason for using a
> hidden toplevel directory. There is not a *strong* reason for not
> doing so either. This subquestion is mainly a bikeshed-type question,
> a matter of personal preference, so there is no consensus to be found.
> Please if you use a hidden toplevel dir just do it, do not complicate
> thing by symlinking outside the directory, which would sabotage the
> original aim of clearly separating generated stuff without increasing
> consensus. TIA.

We have some experience with this kind of question with Debian Python 
packaging.  The standard build system plugin, pybuild, use .pybuild for its 
build files.  This has good and bad points in my experience:

Good:
Usually I don't have to think about it at all.

Bad:
Relative to upstream expectations, the build directory is non-standard so 
sometimes extra effort is needed to run tests in the proper location.

When there are problems, people have to know to look for hidden directories to 
troubleshoot.

When this was first introduced, there was a fair amount of work to adapt to it 
(IIRC, it's been a few years), but since then it seems like tools and people 
have adapted.  I agree that symlinks only complicate the picture.

Personally, I don't see any real benefit of standardizing on (making up an 
example here) debian/.build over debian/build.

Scott K

signature.asc
Description: This is a digitally signed message part.


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

2020-05-02 Thread Andreas Metzler
In gmane.linux.debian.devel.general Niels Thykier  wrote:
[...]
>  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.
[...]

FWIW I did not followup there because symlimking a hidden directory
just complicates things without addressing arguments against using a
hidden directory at all. I have not received a real answer to
20200331172540.ga1...@argenau.bebt.de. - But please bear with me ...

I do think it is a splendid idea to separate generated stuff from
everything else, I think there is no real good reason for using a
hidden toplevel directory. There is not a *strong* reason for not
doing so either. This subquestion is mainly a bikeshed-type question,
a matter of personal preference, so there is no consensus to be found.
Please if you use a hidden toplevel dir just do it, do not complicate
thing by symlinking outside the directory, which would sabotage the
original aim of clearly separating generated stuff without increasing
consensus. TIA.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'