On Wed, 21 Sep 2016 08:44:33 +0200
Ulrich Mueller wrote:
> Obviously they could be identified by their explicit ${FILESDIR}.
My question is because I've had a difficulty understanding how repoman
"sees" the ebuild.
I was under the impression repoman would either have to rely on people to be
go
> On Wed, 21 Sep 2016, Kent Fredric wrote:
>> Under that new scheme, how would I apply patches unpacked into
>> WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use
>> the default src_prepare to process it.
> oh. Right. Huh, I had somehow overlooked there was already a PATCHES
On Tue, 20 Sep 2016 18:14:58 +0200
Ulrich Mueller wrote:
> Under that new scheme, how would I apply patches unpacked into
> WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use
> the default src_prepare to process it.
oh. Right. Huh, I had somehow overlooked there was already a P
On Tue, 20 Sep 2016 18:14:58 +0200
Ulrich Mueller wrote:
> Under that new scheme, how would I apply patches unpacked into
> WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use
> the default src_prepare to process it.
Can you give me a clearer example of what you mean?
pgpPMY7
> On Tue, 20 Sep 2016, Kent Fredric wrote:
> So a reduced suggestion would be:
> 1. Add a PATCHES var to EAPI7
> 2. PATCHES is analogous to SRC_URI, a string
> 3. PATCHES supports USE conditionals
I am not convinced that USE-conditional patching should be encouraged.
Because so far the polic
On Tue, 20 Sep 2016 09:02:41 +0200
Michał Górny wrote:
> Finally, the same though occurred to me as to ulm. People will forget
> to update the variable. They will forget to update it when adding,
> and they will waste their time on build that is going to fail somewhere
> at doinit in the end -- h
On Sat, 17 Sep 2016 00:30:31 +1200
Kent Fredric wrote:
> Just an idea that seemed obvious enough and obviously missing.
Sounds like a great way to discourage people from contributing even
further. I'm going to say that developers leaving mess in their
FILESDIR is rather a pathological case, so w
On Fri, 16 Sep 2016 20:34:49 +0200
Ulrich Mueller wrote:
> That is, similar syntax as for SRC_URI? That would make parsing of the
> FILES variable by ebuilds practically impossible. So presumably, one
> would need another variable similar to A then, containing the files
> from FILES but without t
> On Fri, 16 Sep 2016, Zac Medico wrote:
> If FILES supports USE conditionals,
That is, similar syntax as for SRC_URI? That would make parsing of the
FILES variable by ebuilds practically impossible. So presumably, one
would need another variable similar to A then, containing the files
from F
On 16/09/16 11:20 AM, Ulrich Mueller wrote:
>
> AFAICS that proposal goes into a direction which is somewhat opposite
> to what we have pursued in EAPI 6. There, we have allowed directories
> as arguments to eapply, in order to simplify application of patchsets.
> Now maintainers would have to lis
On 09/16/2016 08:20 AM, Ulrich Mueller wrote:
>> On Sat, 17 Sep 2016, Kent Fredric wrote:
>> 4. Due to referential integrity, it should be trivial to identify which
>> files are needed by a given ebuild, and which files are now redundant,
>> assisting with keeping the tree pruned.
>
> How does
On Fri, 16 Sep 2016 17:20:28 +0200
Ulrich Mueller wrote:
> > 3. Each entry in FILES dictates that the given file is "Used by" the
> > ebuild.
>
> Do you mean "file" in its Unix meaning here, i.e. including
> directories? Or only regular files?
I'd say regular files for now. Mostly because I t
Ühel kenal päeval, R, 16.09.2016 kell 17:20, kirjutas Ulrich Mueller:
> How does a file in FILESDIR get stale? The typical scenario is that a
> patch will no longer be needed after a version bump and pruning of
> old
> ebuild versions. I fear that with FILES the problem would simply be
> shifted: i
> On Sat, 17 Sep 2016, Kent Fredric wrote:
> Just an idea that seemed obvious enough and obviously missing.
> 1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as
> a stand-in for now ).
> 2. FILES contains an array (or perhaps whitespace delimited string) of
> entries (or
Just an idea that seemed obvious enough and obviously missing.
1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as
a stand-in for now ).
2. FILES contains an array (or perhaps whitespace delimited string) of
entries (or perhaps expressions) relative to
${repository_location}/${
15 matches
Mail list logo