Re: Packaging BLAT for Debian

[Andreas Tille <tille@debian.org>]

Hi again,

I'd like to pick up the ball for blat again.  For me it is not yet clear
by what license blat is covered and what might be the role of the KentLib
library[1] plays.  Is it possible to link blat against KentLib and is it
sensible to start packaging this first.

Just to let you know:  The freeze for the next Debian release is coming
soon and it blat should be distributed with the next release we should
hurry up to get this done.  For me it remains unclear who is responsible
for what and role the different pieces of code are playing.

Kind regards

      Andreas.

[1] https://github.com/jstjohn/KentLib

On Thu, Feb 27, 2014 at 12:49:06AM -0800, Jim Kent wrote:
> Yes.  If you could reiterate some of the links,  or if you prefer just
> forward this whole thread to Hiram, it would be great.   Then I can go back
> to wrestling with the ENCODE monster!
> 
> 
> On Thu, Feb 27, 2014 at 12:31 AM, Andreas Tille <tille@debian.org> wrote:
> 
> > Hi Jim,
> >
> > seems like we got in contact to the perfectly right time. :-)
> >
> > I'm happily waiting for your colleagues showing up at the Debian Med
> > list (which I'd strongly recommend for this purpose since I'm just a
> > member of the team and not the whole team ;-)) and repeat that one of
> > them might be interested in our Mentoring of the Month effort
> >
> >    https://wiki.debian.org/DebianMed/MoM
> >
> > Looking forward to a great cooperation
> >
> >     Andreas.
> >
> > On Thu, Feb 27, 2014 at 12:17:09AM -0800, Jim Kent wrote:
> > > 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
> > > >
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de