Re: Re: [MoM] Re: bart - tools for computational magnetic resonance imaging
Hi Ghisvail!
> - Binary packages split-up.
>
> I am not quite sure about the usefulness of the bart-dev package. The final compilation line shows:
...
> i.e. the final output is one executable (bart) with private libraries (libbox, libgrecon...) linked statically. So it looks to me that these libraries are not intended to be used publicly?
There are meant to be used and there are people who are using
them for internal projects. Ofcourse, they currently use the
source distribution of BART, but I think a -dev package would
be useful in the long run. I also have a small image viewer
build on top of the libraries, which I would like to package
eventually:
https://github.com/mrirecon/view
>
> - Licensing of the bart Debian packages.
>
> Since the software is compiled with GSL and FFTW support, the resulting binary should be distributed under a compatible GPL-like license. This may need to acknowledged somewhere, maybe in debian/README.Debian. For an example of such acknowledgement, have a look at how this is done with ITK [1].
I added a README.Debian.
> - Copyright listing.
>
> The output of licensecheck shows that some files have different copyright attributions than yours. For instance:
>
>
> ./matlab/imshow3.m: UNKNOWN
> [Copyright: Michael Lustig 2012 [sx,sy,nc] = size(img);]
>
> Please be super thorough on these, since a non-exhaustive copyright listing is a strong motive for package rejection.
We have permission to re-distribute everything
under the BSD license. I reworded the copyright file to
Copyright: 2013-2016 The Regents of the University of California
2013-2016 BART Developer Team and Contributors
to make clear that there are other contributors who
own copyright themselves.
>
> - lapack-dev -> lapack-dev | lapack.so in your list of Build-Depends in d/control.
>
>
> That way your package can be built with optimized libraries like atlas or openblas.
Sounds like a good idea, but I do not understand it. What
does it mean to depend on "lapack.so"?
Also one can replace liblapack.so using update-alternatives.
Why would it matter what I compile against as all alternatives
should be ABI compatible?
> - Potential overlinkage.
>
> You might want to check these warnings out:
>
> dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/bart/usr/bin/bart was not linked against libgslcblas.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/bart/usr/bin/bart was not linked against libz.so.1 (it uses none of the library's symbols)
Those should be fixed with the new upsteam release.
>Apart from these comments. Looks good on my side.
Thank you for your help!
Martin
G
Reply to: