Re: Packaging BLAT for Debian
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
Reply to: