FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-13-2010, 07:38 PM
Petteri Räty
 
Default mercurial.eclass: change clone destination

On 11/10/2010 07:16 PM, William Hubbs wrote:
> On Mon, Nov 08, 2010 at 10:05:17PM +0200, Petteri R??ty wrote:
>> On 11/08/2010 06:17 AM, Donnie Berkholz wrote:
>>> On 16:42 Sun 07 Nov , Petteri R??ty wrote:
>>>> On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
>>>>> Hello,
>>>>>
>>>>> I'm sending this patch for discussion, what it changes? The change is to where
>>>>> the final clone of repository will be placed, it used to be ${WORKDIR}/${module}
>>>>> (where module usually is the last component of source URI) to ${WORKDIR}/${P}
>>>>> (essentially ${S}). This has few effects:
>>>>> - ebuilds using mercurial.eclass don't need to set S any longer
>>>>> - mercurial.eclass behaves more like git.eclass
>>>>> - it breaks all existing ebuilds using this eclass
>>>>
>>>> Which means that the doing the chance is not allowed as eclasses must
>>>> remain backwards compatible.
>>>
>>> Is that really still the case now that full environments have been saved
>>> for a number of years? Clearly breaking things is unacceptable, but I
>>> could envision someone simultaneously updating the eclass and all
>>> consumers.
>>>
>>
>> There's no full environment saved before the package is installed and I
>> don't see why we should break overlays.
>
> I didn't think we had to care about overlays since they aren't the main
> tree? After all, how can we be sure what is happening in all overlays
> out there?
>
> I could see this, like Donnie says, if he wasn't going to fix all of the
> ebuilds. However I don't see a problem with it since he said he is
> going to fix all of the ebuilds.
>

If there are options that don't require breaking with no big downsides
then we should rather go with them. There usually are.

Regards,
Petteri
 
Old 11-17-2010, 05:43 PM
Krzysztof Pawlik
 
Default mercurial.eclass: change clone destination

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...
 

Thread Tools




All times are GMT. The time now is 11:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org