[Debian-med-packaging] Bug#813438: Iqtree accepted in Debian

[Andreas Tille]

Hi 

On Thu, Feb 04, 2016 at 11:44:45AM +0100, Bui Quang Minh wrote:
> > testing (which is the case if it stays in unstable for five days without
> > any known release critical bug) I will also create a backport for the
> > current stable release Jessie.
> 
> thanks for the update!

You are welcome.
 
> > Since I noticed that meanwhile new versions are released and I intend to
> > upload the latest version with bug fixes.  So I downloaded 1.3.13
> 
> yes this version is desirable as it fixed 3 bugs compared with 1.3.11

I plan to upload the latest version at all time anyway - if you keep the
list updated about releases this makes it more probably that we manage
right in time.
 
> > and a lot of similar errors.  From the preprocessor error message above
> > it seems obvious that dropping sse3 and avx options is not intended and
> > will break the build.  
> 
> that’s right, I have a C++ template that implements the core computational kernel of IQ-TREE. This C++ class is compiled twice, one under SSE3 and another under AVX. Then at run time, IQ-TREE will detect the CPU feature. Depending on the availability of AVX or not, the appropriate kernel will be used. In fact IQ-TREE also has a non-SSE kernel, that can be used. However, I thought that >95% of the computers nowadays support SSE anyway, thus I did not include this switch.

For Intel processors this assumption is most probably true.  However, it
might be the case that some autobuild servers on Debian might fall into
the remaining 5%.
 
> > Does this mean that you intend to support intel
> > processors exclusively?  
> 
> no, I indeed want to support any CPU. I don’t have much knowledge in this deep aspect. Thus, can you advice us how that can be done?

I admit I have no clue about the non-Intel hardware myselves.  If you
ask me enabling the usage of the non-SSE kernel and at the same time do
not require SSE and AVX on non-Intel platforms to build should do the
trick.  Most probably this could be done with some conditional
statements in the cmake configuration.
 
> > In any case I will keep the patch that adds the string "32" to the
> > executable name[3] which IMHO makes no sense on Linux.
> 
> I wanted to make distinction between 64-bit and 32-bit binary, so that users can have both executables actually. But it’s fine if you think that is not necessary for Debian

If you are running a 64 bit machine these are usually multiarch
installations that could at least theoretically execute 32 bit
applications.  Do you think it makes any sense to do this in
practice?
 
> > Finally I would like to let you know that we now have packaged ncl
> > library.  I remember that we discussed this in the past but as far as my
> > weak mind kept it you intended to drop the differences to upstream
> > ncl[4].  When doing a quick diff I can see some differences in the code
> > but I have no idea in how far this is relevant and whether you possibly
> > could forward your patches to ncl upstream to stay in sync with current
> > development.
> 
> my local NCL copy was ~ 10 years old, and that’s was enough for my need. I modified it a bit but can’t remember anymore. I saw recently that they changed a lot. Therefore, right now I don’t have a plan to include the latest NCL version. 

I would welcome a lot if you could do so.  From a maintenance point of
view maintaining different versions of the same code base is considered
bad.  I do not want to force you about this but please consider it in
the not to far distance.  This would be really appreciated.  Just assume
that NCL authors increased the code and you can not profit from it when
sticking to the old copy.
 
Kind regards

     Andreas.

-- 
http://fam-tille.de