Jalview in Debian...

Jalview Developers
1

Hello all !

   I have two pieces of news for you: one good and one bad.

   First, for now more than a week, jalview is part of Debian ! Thanks to all of you who helped me achieve that. You may be interested in the following pages, which are the so called package tracking pages of the various (source) packages jalview is made of in Debian:

http://packages.qa.debian.org/libj/libjaba-client-java.html

http://packages.qa.debian.org/j/jalview.html

http://packages.qa.debian.org/libv/libvamsas-client-java.html

   On these pages, there are a couple of links that may interest you more than other:

   * The bugs box on the right. Some of those may be Debian-specific (i.e. blundering from my side) or packaging-specific (which is probably of no interest to you).

   * The popcon link is the popularity contest in Debian, ie the number of Debian users that have installed jalview. For now, there's hardly anyone, mostly because jalview is in the experimental suite, because it was built against a 'development' version of jmol.

   Some time later, jalview will automatically be imported by Ubuntu, and you'll be able to find similar statistics there, although I can't give you a direct link, I'm aware of none for the time being. You can just look at the raw popcon data at popcon.ubuntu.com.

   This leads me to the bad news: jalview is fresh but already broken. Debian now ships jmol version 12.2.2 (that's the stable release, isn't it ?), and jalview doesn't build against it.

   Although I could tackle porting to the newer jmol, I guess it won't take much time to you. I'm attaching the build failure log in case someone wants to have a look. If no one steps forward, I'll give it a try ;-)...

   Cheers, and thanks again !

  Vincent

jalview-breakage-with-newer-jmol (14.5 KB)

2

Thanks for the heads up, Vincent !

  This leads me to the bad news: jalview is fresh but already broken. Debian now ships jmol version 12.2.2 (that's the stable release, isn't it ?), and jalview doesn't build against it.

  Although I could tackle porting to the newer jmol, I guess it won't take much time to you. I'm attaching the build failure log in case someone wants to have a look. If no one steps forward, I'll give it a try ;-)...

I've been watching the jmol-dev list with feelings both of fear and wonderment - they have just completed a major refactoring in order to support an android build, and I've been looking at the new architecture to see how jalview might be refactored to achieve the same goals. I think some of the changes were already pushed into the 12.2 stream.

I'll take a look at this over the next few days and see if it can be rectified. If it can, I'll push changes to both the 2.7, master and develop branch.

Unfortunately, I was somewhat concerned that this might happen with the packaging. Unless there is an explicit API jar generated by a project, they are almost always likely to change their APIs at every release. Would it be possible to specify a specific Jmol.deb that Jalview.deb requires ? As I understand it, the FTPmasters preserve all older versions.

I suppose the alternative would be to have a 'jalview-jmol.deb' which provides the latest compatible Jmol - either as a virtual package or as a snapshot.

Jim.

···

On 03/11/2011 22:32, Vincent Fourmond wrote:

3

>
> This leads me to the bad news: jalview is fresh but already
>broken. Debian now ships jmol version 12.2.2 (that's the stable
>release, isn't it ?), and jalview doesn't build against it.
>
> Although I could tackle porting to the newer jmol, I guess it
>won't take much time to you. I'm attaching the build failure log
>in case someone wants to have a look. If no one steps forward,
>I'll give it a try ;-)...
I've been watching the jmol-dev list with feelings both of fear and
wonderment - they have just completed a major refactoring in order
to support an android build, and I've been looking at the new
architecture to see how jalview might be refactored to achieve the
same goals. I think some of the changes were already pushed into the
12.2 stream.

I'll take a look at this over the next few days and see if it can be
rectified. If it can, I'll push changes to both the 2.7, master and
develop branch.

  Thanks a lot !

Unfortunately, I was somewhat concerned that this might happen with
the packaging. Unless there is an explicit API jar generated by a
project, they are almost always likely to change their APIs at every
release. Would it be possible to specify a specific Jmol.deb that
Jalview.deb requires ? As I understand it, the FTPmasters preserve
all older versions.

  Actually, that isn't the case. If you think in terms of distribution
(say, squeeze, wheezy, I don't know if that actually tells anything to
all of you), there may exist only one version of a package.

  It is possible to duplicate code and have, say, a jmol-12.1 package
and a jmol-12.2 package, but that's a real pain to maintain, and the
Debian Security frowns upon that: two times the same code means
potentially having to fix security issues twice (keep in mind Debian
provides security support for all of its packages). Basically, this is
accepted as a transition to avoid breaking too many things at once,
but very seldom in a durable fashion.

  That makes it particularly painfull to package Java stuff, as there
are so many tools that make it easy for a java developer to use a
particular version of a library that in general developers are a
little less careful about API breakages.

  I don't know what could be a long-term solution. If this time, jmol
underwent heavy refactoring, API breakages are normal. I hope that
won't happen that often for later versions of jmol. Maybe just raising
the awareness there about which interfaces you use would encourage
jmol developers to stabilize them ? Probably you don't use too much of
jmol's internals to make it a pain for jmol developers to keep the
interface you use constant. Think about it: this means that jmol
upgrades for you would be mostly painless, and that also means that
jalview users would have an up-to-date embedded copy of jmol...

  Cheers,

        Vincent

···

On Fri, Nov 04, 2011 at 09:33:16AM +0000, Jim Procter wrote:

On 03/11/2011 22:32, Vincent Fourmond wrote:

4

Jalview is now patched for Jmol 12.2.4 - which is their latest SVN for 12.2 branch.

Actually, that isn't the case. If you think in terms of distribution
(say, squeeze, wheezy, I don't know if that actually tells anything to
all of you)

:slight_smile: yes - translation is : wheezy==testing, squeeze is latest stable distribution. (for lurkers, check out this page if you're interested: Debian -- Debian Releases).

, there may exist only one version of a package.

agh - right. I forgot about that. Packages are matched on name, not name+version.

   It is possible to duplicate code and have, say, a jmol-12.1 package
and a jmol-12.2 package, but that's a real pain to maintain, and the
Debian Security frowns upon that: two times the same code means
potentially having to fix security issues twice (keep in mind Debian
provides security support for all of its packages). Basically, this is
accepted as a transition to avoid breaking too many things at once,
but very seldom in a durable fashion.

hmm. there are situations where this does have to happen. We expect Jalview to enter such a transition phase in a few months, because I will begin cutting up the code into distinct modules, each with their own versioned API. At the same time, we'll maintain the last release branch, backporting patches if possible, until Jalview 3 is stable and we can completely deprecate the 2.X series. I'd almost bet money that people will still use Jalview 2.X for a few years after that, though!

   That makes it particularly painfull to package Java stuff, as there
are so many tools that make it easy for a java developer to use a
particular version of a library that in general developers are a
little less careful about API breakages.

I don't think that's limited to Java developers ! but that's a story for another list :wink:

   I don't know what could be a long-term solution. If this time, jmol
underwent heavy refactoring, API breakages are normal. I hope that
won't happen that often for later versions of jmol. Maybe just raising
the awareness there about which interfaces you use would encourage
jmol developers to stabilize them ?

I have done, and continued to do this. Furthermore, I'll barrack for a Jmol-apis package to be created (since I want to make an analogous Jalview-apis package too :slight_smile: ).

Probably you don't use too much of
jmol's internals to make it a pain for jmol developers to keep the
interface you use constant. Think about it: this means that jmol
upgrades for you would be mostly painless, and that also means that
jalview users would have an up-to-date embedded copy of jmol...

Don't I know it ! However, since Jmol's architecture is still undergoing massive changes, I don't think we'll see a simple drop-in upgrade path between major versions (ie 12.x transitions) for some time. It was just bad luck that the 12.2 series came out just as you released Jalview's package :slight_smile: hopefully we can time it better next time.

Jim.

···

On 04/11/2011 11:30, Vincent Fourmond wrote:

5

Hello !

   For some reason, I missed this mail ;-)...

Jalview is now patched for Jmol 12.2.4 - which is their latest SVN for
12.2 branch.

   Great !

   An updated version of jalview is currently on its way to unstable...

Actually, that isn't the case. If you think in terms of distribution
(say, squeeze, wheezy, I don't know if that actually tells anything to
all of you)
It is possible to duplicate code and have, say, a jmol-12.1 package
and a jmol-12.2 package, but that's a real pain to maintain, and the
Debian Security frowns upon that: two times the same code means
potentially having to fix security issues twice (keep in mind Debian
provides security support for all of its packages). Basically, this is
accepted as a transition to avoid breaking too many things at once,
but very seldom in a durable fashion.

hmm. there are situations where this does have to happen. We expect
Jalview to enter such a transition phase in a few months, because I will
begin cutting up the code into distinct modules, each with their own
versioned API. At the same time, we'll maintain the last release branch,
backporting patches if possible, until Jalview 3 is stable and we can
completely deprecate the 2.X series. I'd almost bet money that people
will still use Jalview 2.X for a few years after that, though!

   There's no problem with a transition between two different architectures of jalview, especially since, for now at least, no other debian packages depend on it. It's just that maintaining over a long period two versions concurrently means double work, which may as well be justified !

   Debian doesn't prevent users from installing older versions of packages. As a matter of fact, snapshot.debian.org enables one to find any version of a package that ever made it to the archive (excepted those that should never have been there due to copyright/license issues). It's just that if it doesn't work out of the box, you're on your own.

That makes it particularly painfull to package Java stuff, as there
are so many tools that make it easy for a java developer to use a
particular version of a library that in general developers are a
little less careful about API breakages.

I don't think that's limited to Java developers ! but that's a story for
another list :wink:

   Java is one of the very few languages that allows for an easy redistribution of binary-only cross-platform code. This is what makes it easy to pick an already compiled library and stick to it. This is what makes it a pain to package ;-)...

I don't know what could be a long-term solution. If this time, jmol
underwent heavy refactoring, API breakages are normal. I hope that
won't happen that often for later versions of jmol. Maybe just raising
the awareness there about which interfaces you use would encourage
jmol developers to stabilize them ?

I have done, and continued to do this.

   Great !

> Furthermore, I'll barrack for a

Jmol-apis package to be created (since I want to make an analogous
Jalview-apis package too :slight_smile: ).

   ... and great too !

Probably you don't use too much of
jmol's internals to make it a pain for jmol developers to keep the
interface you use constant. Think about it: this means that jmol
upgrades for you would be mostly painless, and that also means that
jalview users would have an up-to-date embedded copy of jmol...

Don't I know it ! However, since Jmol's architecture is still undergoing
massive changes, I don't think we'll see a simple drop-in upgrade path
between major versions (ie 12.x transitions) for some time. It was just
bad luck that the 12.2 series came out just as you released Jalview's
package :slight_smile: hopefully we can time it better next time.

   ;-)...

   Cheers, and thanks for the quick patches !

  Vincent

···

On 04/11/11 17:33, Jim Procter wrote:

On 04/11/2011 11:30, Vincent Fourmond wrote:

--
Vincent Fourmond, Doctor in Physics
http://vince-debian.blogspot.com/