> > > 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 co
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/
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 packag
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
>
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
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 tha
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 mor
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 lo
Hello Niels,
On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
> 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 shor
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,
> >
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. I
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
> sourc
Sean Whitton:
> Hello,
>
> On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
>
>> 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
Hello,
On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
> 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.
Thank you for you
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 s
On 2020-03-09 Sam Hartman wrote:
> 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.
On Mon, 2020-03-30 at 13:54:27 +0200, Simon Richter wrote:
> On 30.03.20 00:52, Guillem Jover wrote:
> > And, of course there are always going to be remaining sticking points
> > not covered by features I or others have in mind, but IMO their presence
> > will still mean there's something to improv
Hi,
On 30.03.20 00:52, Guillem Jover wrote:
> And, of course there are always going to be remaining sticking points
> not covered by features I or others have in mind, but IMO their presence
> will still mean there's something to improve somewhere.
This is the same debate we had in a lot of othe
On Sun, 2020-03-29 at 22:48:04 +0200, Marco d'Itri wrote:
> On Mar 29, Guillem Jover wrote:
> > While it's true that we might need to use such pathnames in debian/rules
> > or debhelper fragment files (which some might consider ugly), IMO that
> > has always felt like a sign that there's something
On Mar 29, Guillem Jover wrote:
> While it's true that we might need to use such pathnames in debian/rules
> or debhelper fragment files (which some might consider ugly), IMO that
> has always felt like a sign that there's something missing in our
> packaging helpers/tools.
If you believe this th
On Mon, 2020-03-09 at 09:23:46 -0400, Sam Hartman wrote:
> 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 fri
(note, this is a barely structured brain dump)
On Tue, Mar 10, 2020 at 08:10:55AM +0100, Niels Thykier wrote:
> >> Though, can you elaborate a bit on why the above approach would be
> >> better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
> >> easy way to declare additional art
On Tue, Mar 10, 2020 at 09:07:57AM +, Simon McVittie wrote:
> On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote:
> > On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > > Standardized way of extracting additional build-time artefacts
> >
> > This reminds me of the BYHAND stuff, I for
On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote:
> On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > Standardized way of extracting additional build-time artefacts
>
> This reminds me of the BYHAND stuff, I forget how that works though.
I think how that works is that at the appropri
On Tue, 10 Mar 2020 at 08:10:55 +0100, Niels Thykier wrote:
> Just to clarify something related. Should debhelper and other tools by
> default archive "certain files of possible interest" (e.g. config.log)?
> Or should we limit it to "on request only"?
I think it would probably make most sense fo
On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
>
Standardized way of extracting additional build-time artefacts
This reminds me of the BYHAND stuff, I forget how that works though.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Simon McVittie:
> On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
>> Simon McVittie:
>>> For example, dpkg-buildpackage could perhaps read one glob per
>>> line from debian/artifacts and hardlink matched files (if any) into
>>> debian/.build/artifacts for collection by a "larger" framew
On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
> Simon McVittie:
> > For example, dpkg-buildpackage could perhaps read one glob per
> > line from debian/artifacts and hardlink matched files (if any) into
> > debian/.build/artifacts for collection by a "larger" framework like
> > sbuild
Hello Julian,
On Mon 09 Mar 2020 at 09:43PM +01, Julian Andres Klode wrote:
> On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. [...]
> [...]
>> The use of a hidden directory is to reduce c
On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. [...]
[...]
> The use of a hidden directory is to reduce clutter and stomping over any
Love the hidden directory.
--
debian developer - deb
Simon McVittie:
Hi :)
> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>> - debian/.build/upstream*
>>
>> These could be used for out-of-tree b
ian.org; debhel...@packages.debian.org
Subject: Re: RFC: Standardizing source package artifacts build paths
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***
I'm concerned about a leading . at least for:
* the debian/tmp replaceme
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 ra
On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. These would have the following form:
>
> - debian/.build/upstream*
>
> These could be used for out-of-tree builds replacing current
>
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 k
35 matches
Mail list logo
