Hi Simon, As you've probably guessed, the correct answer is (A) but it might not be as bad as you think because:
1) Most small Java libraries are actually very easy to package 2) Most updates to small Java libraries are trivial to push through 3) You are not alone - both Debian Med and Debian Java people will help with the workload 4) You can do your plan B as a beginning, so that you do actually work on the Bpipe package first. Don't worry about compiling from source here, just round up the binary JARs and dump them directly in the source package, then once Bpipe is packaged up and working we worry about splitting out the dependencies. What could be a showstopper is if you rely on a JAR for which there is no source or the source is under a discriminatory license. If any part of your software is non-free then the whole thing is non-free. Also some Java software depends on a very particular older version of a library because it's essentially bug-compatible. Debian frowns on this. (Actually, anyone with any sense should frown on this). Compatibility should be determined by regression tests, rather than version numbers, so that library packages can be safely upgraded. So, first job is to make a list of what those libraries are and the versions required so we can at least triage them all - similar to what they did with OpenClinica. Do you have that list? Cheers, TIM On Tue, 2015-02-17 at 09:32 +0000, Simon Sadedin wrote: > Hi all, > > I guess I have a ³simple² question but it might be a bit of a showstopper > - Bpipe relies on a number of java libraries that are fetched in binary > form from online repositories at build time. If I understand Debian policy > correctly, that is not allowable. I checked through the packages and a > number of them seem to be either unavailable in Debian or they are > available but not with recent enough versions. > > If I understand the situation right, my options would be - > > - somehow get all these third party libraries submitted / updated into > debian > > - package the source for all these libraries inside the Bpipe package and > have the package build all the dependent libraries it needs as part of its > own build. > > The first I am afraid would be far beyond the time I have to commit. The > second is probably also quite a lot of work, but its more feasible. > > Are these my only options? > > NB: this seems to be a similar situation to OpenClinica a few years ago. > Thread here: > > https://lists.debian.org/debian-med/2011/11/msg00006.html > > > Cheers / thanks! > > Simon > > On 6/02/2015 7:51 am, "Andreas Tille" <andr...@an3as.eu> wrote: > > >Hi Simon, > > > >I'm writing you as a member of the Debian Med team. > > > >On Thu, Feb 05, 2015 at 06:08:49PM +0000, Tim Booth wrote: > >> It's great to hear that you are using Bio-Linux and want to contribute > >> your Bpipe package. We also have a need for an effective lightweight > >> pipeline system that supports clusters and doesn't rely on a web client > >> (Galaxy) or a mountain of Java dependencies and remote services > >> (Taverna). > > > >+1 > > > >> What we can do do is to submit the package to Debian Med > >> (https://wiki.debian.org/DebianMed) which is what I do with all my new > >> packages where possible. Putting the package into Debian makes it > >> appear in Debian, Ubuntu, Mint and of course Bio-Linux so it's a big > >> win. > > > >+1 > > > >> To have a Debian package one needs first to make the initial package and > >> then to maintain it as new versions come out or bugs are reported. The > >> first bit is hard for you but easy for us. The second bit is where you > >> can make it much easier for us by being the primary maintainer in Debian > >> and handling necessary updates. (Don't worry that you are using > >> Bio-Linux rather than an Debian system - for Java apps it makes no > >> difference.) > >> > >> To this end I've copied this to the Debian Med list. Someone on the > >> list might fancy picking up the package - if not I'll have a look at it > >> myself but it will be a couple of weeks before I have time as I'm rushed > >> on various other jobs. Either way, we'll take you through the initial > >> packaging then make sure you are set up to be the primary maintainer. > >> It's a bit of learning for you but you won't have to swallow the entire > >> 106 page Debian packagers' policy manual ;-) Does that sound an OK > >> plan? > > > >I could also offer to help you getting started in a so called Mentoring > >of the Month project: > > > > https://wiki.debian.org/DebianMed/MoM > > > >In short we would be really happy if you could help you to get the > >software you need into Debian and its derivatives. > > > >Kind regards > > > > Andreas. > > > >-- > >http://fam-tille.de > > > >______________________________________________________________________ > >This email has been scanned by the Symantec Email Security.cloud service. > >For more information please visit http://www.symanteccloud.com > > > >If you have any question, please contact MCRI IT Helpdesk for further > >assistance. > >______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ -- Tim Booth <tbo...@ceh.ac.uk> NERC Environmental Bioinformatics Centre Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB http://environmentalomics.org/bio-linux +44 1491 69 2297 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1424198278.20135.23.ca...@wllt1771.nerc-wallingford.ac.uk