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.

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