On 11/08/10 00:08, Krzysztof Pawlik wrote:
> On 11/07/10 13:07, Mike Auty wrote:
>> On 07/11/10 02:40, Donnie Berkholz wrote:
>>> I read it more closely and realized I was a little confused by the way
>>> you listed all the bullet points mixing together benefits and problems.
>>
>>> So I'll try again: if you really want to do this change, you might want
>>> to consider adding a mercurial-2.eclass instead. Eclasses of this nature
>>> (svn, git, hg, etc) tend to be broadly used outside the tree as well as
>>> within, so breaking backwards compatibility can be a real problem. A new
>>> versioned eclass allows for a much more gradual transition.
>>
>>
>> I've only just jumped into the conversation, but the obvious question
>> is, why not just use ${S} as the location of the working directory
>> (rather than "${WORKDIR}/${workdir}")? That way, if it's set old
>> ebuilds still work, and if it's not set, new ebuilds get the benefit of
>> using ${S}? I can only see a problem with this if there's somewhere
>> that the value of the working directory needs to be known before any of
>> the phases...
>
> Hm.. good idea :) I'm attaching modified patch that uses ${S} by default, so
> it
> will improve the situation and at the same time it won't break existing
> ebuilds.
> Thanks Mike for this suggestion.I've just committed this version. -- Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
