2010/8/16, Adam D. Barratt <a...@adam-barratt.org.uk>: > On Sun, 2010-08-15 at 22:21 +0200, Arthur Loiret wrote: >> 2010/8/15, Adam D. Barratt <a...@adam-barratt.org.uk>: >> > On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: >> >> - Rename the current "llvm" source package to "llvm-2.6" and >> >> replace binaries by versioned binaries. Thus, it is allowed to have >> >> two versions in the archive (the 2.7 version is already versioned), >> >> just like GCC. >> > >> > My primary question is "what does this gain us for Squeeze?" I can see >> > that it could make future maintenance easier when llvm 2.8 hits the >> > archive, but that's not going to the case for Squeeze. >> >> Starting with 2.7, the new convention is to have versioned source >> packages, to allow several different versions to co-exist. > > Apologies if my question wasn't clear. I appreciate why having the > versioned names is advantageous - I'm just not sure what the advantage > is to doing the renaming for 2.6 in squeeze, rather than in squeeze+1. > > So far as I can see, the current packages are already co-installable, > albeit under the names "llvm" and "llvm-2.7"; that's not as clean as > might be preferable, but it would work.
The current binaries packages from "llvm" should be provided by "llvm-defaults", which would Depends on the versioned 2.7 binary packages from "llvm-2.7". The current binaries packages from "llvm" have to be renamed to some versioned binaries packages then. In other words, here is what I want for squeeze: * llvm-2.6 provides libllvm-ocaml-2.6-dev, llvm-2.6, llvm-2.6-dev, llvm-2.6-doc, llvm-2.6-examples, llvm-2.6-runtime, llvm-2.6-source. The binaries package have to be renamed, and some files inside them have to be versioned. * llvm-defaults provides llvm, llvm-runtime, llvm-dev, libllvm-ocaml-dev. They would all Depends on the corresponding versioned packages and just provide symlinks. So, when an user installs "llvm", it will also install llvm-2.7 and symlink, for example, /usr/bin/llc to /usr/bin/llc-2.7. * llvm-2.7 provides libllvm-ocaml-2.7-dev, libllvm2.7, llvm-2.7, llvm-2.7-dev, llvm-2.7-doc, llvm-2.7-examples, llvm-2.7-priv-dev, llvm-2.7-runtime, llvm-2.7-source. Already the case. Very most users want to use 2.7 rather that 2.6. It would just make their life easier by just asking them to install "llvm-dev" and use unversioned binaries. As I already said, those changes are smooth for the archive. >> >> - Upload a package called llvm-defaults which would provide the >> >> binaries for the default (2.7) version. It can be found in its current >> >> state here [0]. Also like GCC. >> > >> > The llvm-defaults package begins producing the llvm binary package, but >> > build-depends on "llvm (>= 2.7)". As the latest version of llvm in the >> > archive is 2.6-9 and the version built from llvm-defaults would be 0.1, >> > that would make the package unbuildable. >> >> This should be "llvm-2.7 (>= 2.7-1)", indeed. Thanks, fixed. > > On a related note, the version of at least the llvm binary package would > also need to be greater than the current 2.6-9. apt won't view llvm_0.1 > as requiring an upgrade from an already installed package of a higher > version. The llvm-defaults 0.1 source package builds 2.7-1 binaries, see debian/rules. This package still needs a bit of work, but not on this side. Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinv-l4vzkbxnebeqmsn=apvrjsvazvdyjtvc...@mail.gmail.com