>> Sure it is. You could just generate the files needed during the
>> post-destroot phase. Something like this:
>>
>> 1) loop through ${python.prefix}/{bin,etc,share,lib,libexec}
>> 2) output into 'select' files: base, none, etc.
>
> And which port is supposed to install these files?
>
> Multiple p
On 05/10/12 19:53, Sean Farley wrote:
> This is not possible as port select always needs a base file which
> cannot be shipped with any of the selectable port options. This is why
> we have the *_select ports; their only purpose is to install this
> base file.
>
>
> Sure it is. Yo
>
> This is not possible as port select always needs a base file which
> cannot be shipped with any of the selectable port options. This is why
> we have the *_select ports; their only purpose is to install this base
> file.
>
Sure it is. You could just generate the files needed during the
post-de
On 05/10/12 01:47, Sean Farley wrote:
> I like the new feature that (2) brings but before I submit my patch,
> there a few notes and issues:
>
> i) it should be possible for the python-1.0 group to create a "port
> select" on the fly (port select --set mercurial mercurial27, port
> select --set me
tortoisehg @2.1.2 devel/tortoisehg
>
> Oh, right. Well if that needs to work I guess there's no choice but to
> make mercurial replaced_by py-mercurial.
>
> I really don't think it's unreasonable for mercurial and its dependents
> to just
On 05/06/12 22:33, Daniel Ericsson wrote:
> hg-forest isn't even compatible with mercurial 2.x, without a
> maintainer or a replacing port can we just remove it? or do we need a
> grace period as the guide says?
If the port is broken already for the last 6 months after mercurial was
upgraded to 2.
> Although someone always complains when they have to
> install n+1 ports instead of their current n...
Maybe not with pre-built binaries ;-)
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosf
python/py27-hggit
> py27-hgsubversion @1.4python/py27-hgsubversion
> py27-hgsvn @0.1.9 python/py-hgsvn
> tortoisehg @2.1.2 devel/tortoisehg
Oh, right. Well if that needs to work I guess there's no
On 6 maj 2012, at 21:14, Sean Farley wrote:
>> I didn't go into the fact that there are some ports depending on mercurial
>> and I wanted to give those a target to depend on that included the python
>> version. But with 24, 25 being on the way out and most ports defaulting to
>> 27 it probably
> I didn't go into the fact that there are some ports depending on mercurial
> and I wanted to give those a target to depend on that included the python
> version. But with 24, 25 being on the way out and most ports defaulting to 27
> it probably will be an issue that goes away.
I have about ha
On 6 maj 2012, at 15:01, Joshua Root wrote:
> On 2012-5-6 22:30 , Daniel Ericsson wrote:
>> Hi,
>>
>> I want to move mercurial to allow for installation with any version of
>> Python, that's supported and the user have chosen as their selected version.
>
> Just take the current portfile and add
t's gonna be
> another cycle of mixed Python installations.
>
> Mercurial is mostly just a python package, with all the help one gets from
> the python portgroup to add different subports for different versions my
> first thought is actually to deprecate mercurial and rename the po
ackage, with all the help one gets from the
python portgroup to add different subports for different versions my first
thought is actually to deprecate mercurial and rename the port to py-mercurial.
Is there any reason we should keep the old port around beyond a replaced_by
keyword?
Some pe
13 matches
Mail list logo