[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Packaging Mauve and libClustalW



On Thu, 13 Mar 2008, Robert Edgar wrote:

I am always happy to work with people who want to use muscle, but the
message below is complete greek to me. Somebody needs to explain in language
I understand what I might be able to do to help.

Ahh, OK.  Just have a look at

   http://gel.ahabs.wisc.edu/mauve/source/mauve_2.1.1/

There is an archive libMUSCLE-1.0.0.tar.gz.
That's why I wrote:

      http://gel.ahabs.wisc.edu/mauve/source/mauve_2.1.1/

Aaron, a new library tarball libMUSCLE-1.0.0.tar.gz occured at this
location for version 2.1.1 and while you used version 1.0.0 you
mention in the file
AUTHORS:
    It contains bugfixes and new features to the original 3.6 code. But
upstream now has version 3.7.

I have no idea what bugfixes and new features Aaron has added to muscle 3.6 code - perhaps somebody with more knowledge of muscle code
than me should verify the difference.

Moreover I wrote:

 So I _really_ like your atempt to build a
library and I would love to convince the muscle authors to build their
binary linked against this library,

I *really* like Aarons strategy to build separate bundles of libraries
that might be used by different projects (just see the download URL
above for libGenome and libMems).  This is perfectly the right way to
go to share code between projects and I would support this strategy
at any expense.

If I understood things right Aaron needed some code from the ClustalW
project for libMems and thus he builded a library from the original
ClustalW project.  Because there are some licensing issues with ClustalW
(that I do not completely understand, but Charles Plessy might comment
on this and there is a chance of replacing ClustalW by Muscle I guess
Aaron followed his strategy and changed your source that way that a
library is builded.  This is a very clever idea but IMHO only if this
strategy is adopted by you as the original author for your future
releases.  Otherwise Aaron would always have to to the same work to
change your tarball to something that builds the library.

To simplify this my suggestion would be that you might take over the
automake / libtool stuff into your upstream source to enable building
a library from your original tarball.  This would mean some extra effort
at your side but we would be willing to sort out any problem this might
cause to enable you a smooth update of your source.  The profit on
your side would be that you might get a coworker in Aaron who might
send patches for bugs or might add new features because he has a
vital interest in having (lib)Muscle in a good shape.


Further I wrote:
Could you please clarify things.  My prefered way to go would be:

  1. Take the latest Muscle upstream source (including patches for
     gcc 4.3)

This is related to the Debian package which has - if I understood the
changelog right - some patches for gcc 4.3.  I hope Charles will
provide you with all information you need.

  2. Choose a new version number.

This is related to the Debian changelog entry:

    New upstream version, buildable with GCC 4.3 (Closes: #462707)
    The version number was not increased upstream when the sources were
    changed. We name this new version in Debian "3.70+fix1".

So as a general advide: Please change the version number if the content
of your distribution tarball changed.  Your users will probably not
notice the change which would be a shame.

  3. Change the build process using automake / libtools to build
     a dynamic and static library from muscle code and link the
     executable against this library.

This is refering to the process I wrote above.

  4. Link Mauve binary against this library.

Just ignore this last step - it is intended for Aaron and means
that I would suggest him to use your tarball (once it builds the
library) instead of providing his own because finally this would
lead to a fork.

I'd volunteer to provide any help that might be needed but please try
to avoid confusing your users by using different versions that have
good chances to drift away from each other.

I hope this is clear. ;-)

Feel free to ask again if anything remains unclear.

Kind regards

      Andreas.

--
http://fam-tille.de


Reply to: