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 will be an issue that goes away. > > I have about half of this work already done in my own local repo. > Would you like me to finish this up and create a ticket(s)?
Go for it! <snip> > >> $ port list depends_lib:mercurial >> hg-forest @20101118 devel/hg-forest >> py-mercurial_keyring @0.5.0 python/py-mercurial_keyring >> py24-hgsvn @0.1.9 python/py-hgsvn >> py25-hgsvn @0.1.9 python/py-hgsvn >> py26-hggit @0.3.1 python/py26-hggit >> py26-hgsvn @0.1.9 python/py-hgsvn >> py27-hggit @0.3.1 python/py27-hggit >> py27-hgsubversion @1.4 python/py27-hgsubversion >> py27-hgsvn @0.1.9 python/py-hgsvn >> tortoisehg @2.1.2 devel/tortoisehg > > The forest extension is mostly dead, having been replaced with subrepos: > > http://mercurial.selenic.com/wiki/ForestExtension > > so I would recommend removing it. Same with hgsvn (replaced_by hgsubversion). 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? I do think the replaced_by is a bit heavy handed if it works like explained in the guide, swapping out peoples hgsvn install for hgsubversion on upgrade feels wrong even though hgsubversion might be a better approach. Is there a precedent for stopping new installs of a port but not swapping out peoples existing installs? -- Daniel _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
