Subject: Splitting devel/mercurial
To: None <>
From: Peter Schuller <>
List: tech-pkg
Date: 07/23/2006 21:18:27

I wanted to package cvs20hg in wip, but ran into the problem that rcsparse (a 
dependency of cvs20hg) requires Python 2.4. cvs20hg requires both rcsparse 
and the mercurial libraries; so if devel/mercurial has been installed with 
Python 2.3, there is breakage.

Joerg suggested to me that a good way to fix this is to split devel/mercurial 
into it's backend/frontend components, allowing the backend to be installed 
for multiple Python versions. I would like to try to come up with an 
appropriate patch to do this.

My initial thought is to divide it into devel/py-mercurial and 
devel/mercurial. The former being the backend and the latter the front-end 
scripts. However, it strikes me as a bit ugly to just replicate the Makefile 
from devel/mercurial into devel/py-mercurial and then make minute changes to 
both. Future changes would likely have to be made to both packages. 

Perhaps it would be better to have a shared 'base' package with 
shallow "front-end packages", like is done with certain other packages I 
believe (though I cannot come up with an example from pkgsrc atm). The 'base' 
package would then contain a couple of contionals to control whether the 
backend or the front-end is installed.

The two options then are:

   devel/py-mercurial (copy of current devel/mercurial with slight changes)
   devel/mercurial (slight changes from current package)


  devel/py-mercurial (base package with conditionals)
  devel/py-libmercurial (backend package)
  devel/mercurial (front-end package)

Where the latter would involve py-mercurial and mercurial to be Makefiles that 
set some variable and then just includes the appropriate .mk from 

Does any of these options sound reasonable? Any feedback would be greatly 

/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <>'
Key retrieval: Send an E-Mail to
E-Mail: Web: