[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Clojure versioning

Hi Matthew,

On Sun, Aug 22, 2010 at 10:02:04AM +0100, Matthew Johnson wrote:
> There's probably also a third: python has a version-dependent compiled format,
> which is created when you install the library (I think) and (presumably)
> rebuilt when you upgrade python. We could do something like that here - 
> but I don't know if it's feasible, since I know nothing about clojure.

This may cause problems if an app links from Java to Clojure, as we
would need the Clojure compiled libraries around.  AIUI, the interface
(but not the implementation) of the Java->Clojure glue is identical
between Clojure versions, so it may work if we AOT compile both at
build and install time.  But this may be too much work, and there
may be other subtle issues I haven't thought about.

> I don't like either solution very much. Of the two, what I would prefer is:
>  - version clojure itself
>  - have clojure be a metapackage depending on the current version
>  - things b-d on clojure and depend on clojureX.Y, with AOT compilation
>  - when you upgrade clojure, add a new clojureX.Y, replace clojure metapackage
>  but leave the old clojureX.Y. At this point everything in the archive still
>  works, depending on the old clojureX.Y
>  - slowly rebuild all the libraries to use the new clojure/clojureX.Y
>  - when nothing depends on the old clojureX.Y, remove it from the archive
> Helper tools can do the dependency calculation for you, so the rebuilds might
> not even need source changes. It might also mean that during the transition you
> need both versions of clojure installed (but this should only happen in
> unstable/testing), but I think that's  better than building multiple versions
> of each package. There are also issues of two libraries being used by the same
> program, only one of which has been upgraded, which will have to be considered.

Actually, I am beginning to prefer this solution.  What do you
think the helper tools should look like?  One idea is to have a
.mk file in /usr/share/cdbs/1/class which defines a clojure.version
environment variable in DEB_MAVEN_ARGS and declares a substvar, say
clojure:Depends.  The individual package would then be responsible for
replacing the clojure version number in pom.xml with ${clojure.version}
(e.g. using maven.rules) and using either ${maven:Depends} or
${clojure:Depends} (for non-maven builds) in debian/control.  Or do
you think there is a cleaner way to do this?


Reply to: