> > I've run the attached script to find duplicates of packages from
> > sage-on-gentoo in science. The output was:
> > $ ./find-overlay-dups.sh
> > sci-chemistry/jmol
> > sci-libs/fplll
> > sci-libs/givaro
> > sci-libs/iml
> > sci-libs/m4ri
> > sci-libs/symmetrica
> > sci-mathematics/gap
> > sci-mathematics/polybori
> > What do people think about merging those versions in the science overlay
> > and removing them from sage-on-gentoo (or vice-versa)? Probably in most
> > cases there are additional fixes in sage-on-gentoo that science users
> > could benefit from (or at least should hurt nobody)?
> Since Christopher and I have access to the science overlay we should
> do some clean up and synchronization.
> Let's see case by case:
> jmol, there are a few differences between mine and the science overlay,
> jeffro and I are not in tune regarding EAPI and that's the main source of
> differences (last time I looked).
> fplll, givaro, iml, m4ri and polybori we are probably ahead. In fact we
> probably put them in science in the first place. symmetrica and gap we are
> probably ahead as well because I am not sure anyone else maintain them.
> Synchronization requires some time.
> About merging. Why not if you are ok with our cruft....
Well, just remove the cruft ;)
> like old pexpect that has moved out of the tree, our own python ebuild (until
> 2.7.3 is finally released), I carry a special version of R for OS X on prefix
> (have to fill the bug for that one). old networkx because the one we need as
> dropped of the main tree....
One thing that comes to mind: Github has some really giganto-awesome
features it seems. You seem to use them and since science is hosted on
gentoo's infrastructure you don't have the issue tracker and online pull
request mangling. Actually, it would be great to have those for