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

Re: Freeze for LLVM packages



2010/8/15, Adam D. Barratt <adam@adam-barratt.org.uk>:
> On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote:
>> We would like to make llvm
>> 2.7 (which is already used by clang and openjdk) the default version,
>> but some packages (ldc and python-llvm) still need llvm 2.6.
> [...]
>> The things to do would be:
>>    - 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. The binary
packages built from the current "llvm" source package have to be
renamed to some versioned binary packages. So, if the package has to
go threw NEW anyway, why not make it follow the new convention by the
same occasion?


>>    - 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.


>>   - Do a last upload of llvm-2.7, clang and llvm-gcc-4.2 which fixes
>> the remaining open bugs
>
> llvm-gcc-4.2 FTBFS on i386, although there doesn't seem to be an open
> bug for that.

Yes, I have a debug build running already.


Thanks,
Arthur.


Reply to: