This update would require a complete rewrite from scratch of the latest ebuild version we have in the tree (1.7). OTOH, if it were down to my decision, I would drop the java herd maintainership (and go as far as removing the ebuild altogether) since it has a single rdep on a sci-biology ebuild: $ qgrep -v dev-java/biojava dev-java/biojava/biojava-1.6.ebuild:# $Header: /var/cvsroot/gentoo-x86/dev-java/biojava/biojava-1.6.ebuild,v 1.1 2009/01/25 19:33:17 weaver Exp $ dev-java/biojava/biojava-1.7.ebuild:# $Header: /var/cvsroot/gentoo-x86/dev-java/biojava/biojava-1.7.ebuild,v 1.2 2010/03/20 13:39:10 betelgeuse Exp $ sci-biology/mauve/mauve-9999.ebuild:CDEPEND="~dev-java/biojava-1.6 So the question is: do we really want to bump this package? https://github.com/biojava/biojava Quite a few modules as you can tell, which I'm sure would require a trillion dependencie more dependencies to be installed/updated.. etc. Further, biojava has NEVER been stabilised. Conclusion ? Reproducible: Always
@sci-biology: Hi! As far as I can tell, this ebuild belongs to the sci-biology/ directory. Truth to be told, we're not interested in maintaining biology libraries, even they're written in Java but we're happy to help out if necessary. Do you want to take over maintainership of this ebuild? If yes, please let us know.
Discussed with jlec: this package is moving to the sci-biology/ directory and the sci-biology herd will co-maintain it with us.
Moving completed. This ebuild now lives in sci-biology/. Give us a shout if you need help with the bump.
(In reply to Patrice Clement from comment #3) > Moving completed. This ebuild now lives in sci-biology/. Give us a shout if > you need help with the bump. We need help. No time and no knowledge about java packaging.
I'm afraid I may have to last rite this as well as Mauve. The legacy versions of BioJava (up to the not-so-old 1.9.1) depend on commons-dbcp 1, which doesn't build with Java 7 or later. While dealing with another revdep, I found that commons-dbcp 2 isn't massively different and some light patching might suffice. I really feel that it's not worth my time though as the in-tree version is ancient and no one seems to care. Mauve is a live SVN ebuild and having looked at the current state of the repository, I'd say it's almost certain that the ebuild no longer works. Once you get rid of this, sci-biology/mauvealigner, sci-libs/libgenome, and sci-libs/libmems also become redundant. We can advise in #gentoo-java but I'm afraid we're not going to do this for you.
After discussing this with soap, sci-biology/{biojava,mauve,mauvealigner} have been last-rited. I spared sci-libs/libmems because it was updated very recently. I also spared sci-libs/libgenome because even though it is officially dead upstream, libmems still uses it for some reason.
# James Le Cuirot <chewi@gentoo.org> (07 Feb 2016) # BioJava depends on commons-dbcp:0, which requires Java 6. Even the # latest "legacy" version 1.9.1 does so and no one wants to do the # difficult bump to 4.1.0. Mauve depends on BioJava but being a very # outdated live SVN ebuild, it probably doesn't work anyway. This goes # for Mauve Aligner too. Removal in 30 days. See bug #556470. sci-biology/biojava sci-biology/mauve sci-biology/mauvealigner
Also added dev-java/byecode to this list. DESCRIPTION="Biojava bytecode manipulation library" HOMEPAGE="http://biojava.org" SRC_URI="https://dev.gentoo.org/~serkan/distfiles/${P}.tar.bz2" Ebuild was never stabilised, Serkan left Gentoo a while ago this stuff is probably broken anyway.
It's gone.
I do not code in Java and while agree from a user's experience all java packages are bulky, with plenty of .jar bundled here and there ... sci-biology/ is probably not going to improve the affected packages. However, Gentoo is useless to the the bioinformatics community if it lacks sci-biology/ applications and libraries, where biojava definitely belongs. I am very disappointed by Gentoo rules, the more effort it takes to add a package the faster it gets dropped from the tree. I have over 900 commits to science overlay since 2010 and as I see, my efforts are useless if the packages get moved to the main tree and then dropped. No, please do not ask me to become a full-time dev, unless Gentoo changes its own habits and keeps packages in the tree as much as possible. If a package landed the main tree and likely somebody uses it, it shall not be dropped just because it seems it is not up-to-date or because interpreter deps are to be dropped for another reason. Please also check if a package is to be dropped whether it is in an overlay. You forgot sci-biology/mauve-9999 in science overlay. Searching for a reason why mauve disappeared took me a while until I found this bug about biojava. Mauve is a maintained project and there are maybe one or two other competitive packages in the world at all (but Gentoo does not offer them). So you dropped the only alternative. http://darlinglab.org/mauve http://darlinglab.org/mauve/snapshots/2015/2015-02-13/linux-x64/mauve_linux_snapshot_2015-02-13.tar.gz http://asap.ahabs.wisc.edu/mauve-aligner/mauve-developer-guide/compiling-mauvealigner-from-source.html https://lists.sourceforge.net/lists/listinfo/mauve-users
Martin, while I partially agree with you, the Gentoo community as a whole cannot be held back by ancient deps. Other non-sci parts of the tree also drop packages if they cannot be built with recent toolchains. A significant part of the problem is the bioinformatics community itself: it develops half-baked software, packages them with even shoddier buildsystems (https://github.com/samtools/htslib/pull/137 no mom! I prefer writing my broken Makefiles myself, by hand, because I'm smarter than Automake!). Specifically Martin, it's not just about adding packages to the tree (or even the overlay). Ebuilds need to be healthy and maintained. Adding stuff to the tree is the easiest part of that lifecycle. And unless someone steps up and fixes the problem (with biojava, for instance), we can't carry such broken things for ages. So, if you're willing to fix the package (I have 0 knowledge about Java, and so does jlec), then go for it. Otherwise, it goes.
I fully agree samtools/htslib/tabix inter-dependencies are a mess and unfortunately we need to keep them all and at various versions (as the authors recycled commandline switches for a different purpose, never version lack temporarily features present in former versions, etc.). My java knowledge is also zero, sorry. I am as you see able to put up some ebuilds building using ant and even maven but that is about it. If biojava/mauve landed the tree once, it was advanced enough to stay. It did compile, it did work. How can you attract users to choose Gentoo if the next day a package they use disappears? A bug like this should have been open for 2 years at least before a package goes away. I did not even sync for more than half a year. And these changes even prevent me to do so on other machines. It is couter-productive. Would Gentoo be less pesky about binary packages lots of troubles would be less pertinent and packages could go live. Gentoo will never have things like cytoscape either (see Gentoo bugzilla and compare with other linux distros). ;-) Of course I agree compiling from scratch is much better, and these packages really can take the advantage of Gentoo because they are CPU intensive.
