Subject: Splitting devel/mercurial
To: None <tech-pkg@netbsd.org>
From: Peter Schuller <peter.schuller@infidyne.com>
List: tech-pkg
Date: 07/23/2006 21:18:27
Hello,
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)
Or:
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
py-mercurial.
Does any of these options sound reasonable? Any feedback would be greatly
appreciated.
--
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org