Re: libjgrapht0.6-java_0.6.0-7_amd64.changes is NEW
On Tue, Sep 01, 2009 at 12:23:08AM +0200, Steffen Moeller wrote:
> Michael Koch wrote:
> > On Mon, Aug 31, 2009 at 05:28:25PM +0100, Matthew Johnson wrote:
> >> On Fri Aug 28 16:44, Steffen Moeller wrote:
> >>> I had felt that when the user apt-get installs libjgrapht-java, he should be asked about
> >>> the version he wants to install. Also, I did not want to disturb packages that depend on
> >>> libjgrapht-java today. If I had libjgrapht-java provided by the libjgrapht0.6-java package
> >>> and by libjgrapht0.7-java, then an apt-get dist-upgrade would render something previously
> >>> working suddenly unusable.
> >> Well, I'm definitely of the opinion that the user should _not_ be asked
> >> about the version he wants to install and, in fact, the user should
> >> generally not being typing `apt-get install libjgrapht-java'.
> >>
> >> The dependency system should be good enough to handle this without
> >> sudden transitions. If it's backwards incompatible surely you should
> >> change the package name and things should be depending on the old name.
>
> Yes, I agree.
>
> >> (For those in the debconf/post-debconf discussions, this is precisely
> >> why I want to reformulate our version handling policies for Java)
> >
> > +1
> >
>
> libjgrapht0.6 is already a separate package. And if it doesn't provide libjgrapht, some
> currently installable package would become uninstallable. Matthew is right in that the
> dependencies to libjgrapht-java, rather than to its (now) versioned counterpart, shall be
> deprecated. But for now, they have to stay.
>
> I definitely want /usr/share/java/jgrapht.jar to be on the system, since many programs do
> depend on such. There can only be one such link at a time, but this is fine, I think.
>
> > The question is about the most evil we could do.
> You are certainly not commenting on the package that I had just uploaded.
Well I guessed only from what you wrote above.
I checked the archive now and its not better. You made libjgrapht-java an empty
package that depends on the package with the latest API. This breaks when packages
depend on libjgrapht-java and libjgrapht-java suddenly depends on a newer
API-incompatible version.
IMO a possible solution would be to have two (or more) packages and let other
packages using jgrapht (Build-)Depend on the version they need. E.g. libjgrapht-java
could always be the latest API and libjgrapht0.6-java is an older API which some
apps can use. Only one of these packages may provide the jgrapht.jar link as otherwise
we would need conflicts between the packages. When an app needs an older version
of jgrapht it needs to explicitely reference the versioned jar (which would not be a bad
idea anyhow as we otherwise force FTBFS on libjgrapht-java API updates).
Cheers,
Michael
Reply to: