Re: Packaging BLAT for Debian

Disabling the pslCheck seems like the sensible and pragmatic thing.

I'm going to write a short note introducing you to Hiram Clawson, and also Ann Zweig our project manager (and Hiram's boss). It is actually part of our grant to package the tools in ways to make it easier for people to use them. Our current system is not so bad, but it requires people to actually read the README, and set an environment variable. This was state of the art in 1985, but not the

config

make

make install

people are used to these days, never mind a RPM or anything more recent, and most of the younger programmers get lost.

I do think we want to do some renaming of directories and the like as part of this process, and ideally end up with all the code that is under one license under the same subdirectory. It's somewhat close to that, but there are enough exceptions to be a pain. We switched from CVS to git about 2 years ago in large part to make moving directories around much less of a pain in the butt, so we _can_ do this now, but it's been sort of a back burner thing, and is only about 10% complete.

Anyway, we are paid by the taxpayers to do this sort of work, and will make some time for it. We would welcome your help, and getting it into Debian is as good a starting point as any, better than most if we have support from that group.

Take care,

Jim

On Wed, Feb 26, 2014 at 11:16 PM, Andreas Tille <tille@debian.org> wrote:

Hi Jim,

On Wed, Feb 26, 2014 at 10:33:59PM -0800, Jim Kent wrote:
> I'm glad you isolated it to the -O2.

:-)

> I don't think there's a super easy way to cut pslCheck out of the whole
> 1,200,000 UCSC genomics source tree.

For the moment I simply disabled this check. I guess it is also this
way sufficient to detect potential problems (and it was not the pslCheck
that failed in the first place).

> I would, on the other hand, be very
> happy for you to take on the job of packaging up that whole source tree for
> Debian. I could refer you to a less busy member of my staff, Hiram
> Clawson, who has a _lot_ of experience helping people get that to build.

This is a very cool offer. I actually have thought about packaging the
whole UCSC genomics source tree as well since it obviously contains
several tools that perfectly fit in our scope. I wonder whether Hiram
might even like to learn something about Debian packaging. In our team
we have quite some tradition in mentoring people as you can see here:

https://wiki.debian.org/DebianMed/MoM

Perhaps it comes handy if somebody in your team is capable to create
Debian packages which in the end is not more than wrapping up the build
process into some sceme.

BTW, when I inspected the jksrc source tree (and also in the specific
case of the blat source) I realised that it might make real sense to
enable dynamic linking of the tools against the static libraries you are
creating. The Debian way to do this would be to create two packages:

lib<name> containing the dynamic libraries
lib<name>-dev containing the static libraries and header files

To approach this easily it is quite convenient to use either GNU
automake or cmake (at your preference) since these build systems easily
support the creation of dynamic and static libraries in parallel. This
would also simplify the hancling of MACHTYPE in your makefiles since
these Build systems are capable to handle this automatically. In short:
before we might start packaging the whole source tree it would be quite
sensible to switch to an advanced build system which would be also in
your profit at the end.

> The licensing of it is quite complex alas. There are three main parts:
>
> - a small part which is owned by me in a directory called jkOwnLib, and in
> the blat directories

This would probably make a separate library package. However, you might
consider a name which is more descriptive than jkOwnLib.

> - a medium sized part that contains stuff we regard as generally useful
> which is essentially public domain, but that we are happy distributed under
> a BSD or MIT license

Cool. That would be very interesting.

> - a large part that is genomics in general, and UCSC Genome Browser in
> particular specific that is owned by UCSC and has a license much like blat
> - free for personal, academic, and non-profit use, and requiring a license
> for commercial use. In this case the licence needs to come from UCSC
> (contact Will Hale) rather than Kent Informatics (contact Heidi Brumbaugh).

In case we have a good plan about the technical details we should
probable contact these persons regarding the licensing.

Kind regards

Andreas.

--
http://fam-tille.de