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
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
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.
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
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
>
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
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
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 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
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
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
(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
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
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
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
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"
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
> >
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
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 -
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
rg; 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 replacement
* the r
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
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
27 matches
Mail list logo
