Re: [SRU] non-free/clustalw and non-free/clustalx relicensed to LGPL-3+.
Le Wed, Apr 06, 2011 at 10:44:38PM +0100, Adam D. Barratt a écrit :
>
> clustalx: 288 files changed, 57040 insertions(+), 40805 deletions(-)
>
> I think that's far too large a change to be making in stable, even if it
> would move the software out of non-free.
>
> clustalw is a bit better, once the build system noise is removed:
>
> 36 files changed, 295 insertions(+), 257 deletions(-)
>
> The changelog isn't exactly verbose as to what those changes represent,
> however. Additionally, would the old clustalx continue to work as a GUI
> to the new clustalw?
>
> > However, since the current clustalx and clustalw
> > packages are not part of Debian, would it really be considered an upgrade ?
>
> If it's not an upgrade, then you're asking us to add two completely new
> sources packages to a stable release. I can only recall one instance of
> that happening in recent years, which was openssh-blacklist and
> introduced via the security archive.
Hi Adam,
First of all, thank you for your answer. I know that I am asking for someting
unusual and I am very pleased that you took the time to consider it. Given of
how easy it is to use backports (that I can prepare), I think that one of the
main points of adding clustalw and clustalx to Stable would be to say a big
“thank you” to the upstream developers for freeing their code.
Regarding the quality of the clustalw 2.1+lgpl-2 and clustalx 2.1+lgpl-1:
- Their previous upstream release, 2.0.12, was uploaded to Debian since
October 2009. No RC issues have been found, and the reason why clustalx did
not make it in Squeeze related to difficulties with (auto)building on non-free.
(This is not a complain).
- Most of the diff between 2.0.12 and 2.1.0 is related to autoconf/automake.
- clustalx does not need clustalw. They both implement the same algorithm,
but… ahem… clustalx contains a copy of clustalw that does not have the
necessary autoconf/automake bits to allow building both software from
the same upstream tarball. I asked upstream if this could be corrected
but their answer is that from 2.1 they want to limit further changes in
the 2.x branch to the strict minimum. This is actually is good for us:
only bug fixes, no new features.
I understand your decision for clustalx. I think that there would still be a
benefit to have clustalw in main for Squeeze, in particular for the generation
of entirely Free Squeeze derivatives for science. While we offer a large number
of alternatives, Clustal W is the reference in its field.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: