Re: [Summary]: RFC: Standardizing source package artifacts build paths
> > > 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
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
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
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
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
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
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
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
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
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'
