Gianfranco Costamagna wrote:
> llvm maintainer (Sylvestre) says that llvm-3.4 is going to disappear
> (not before jessie, but somewhen after), and llvm-3.5 is built
> correctly on arm{el,hf}.
>
> Isn't it better to just upload with llvm-3.5 and do some binNMUs
> instead of using the old one and be hit (or be a blocker) for the
> future RM llvm-3.4 bug?
>
> I'm just wondering if there is something behind the 3.4 decision.Debian-release wrote: > *Remember*: On the 5th of November, the version of your package *in > testing* must be in its desired state for Jessie. I think we will need to do that, at an appropriate point in the release cycle. I'd say just after the release is out, rather than now. * Rebuilding packages on armel and armhf could take quite some time. * Assuming the objects built with 3.4 are not compatable with those built with 3.5, packages might need to be rebuilt in dependency order, which I don't know if we have automated. * The newly built stuff would have no testing compared with the stuff in the archive. * I don't know if simply rebuilding ghc with the new llvm works. (I don't even know what the root cause of the failure is.) I know that ghc contains llvm code generation and that it has had to be patched in the past for compatability with different versions of llvm. * There would probably be some bootstrapping step in building ghc with this change. I haven't thought out how it would work. * We will want to be upgrading to a new ghc after jessie anyway, and it seems likely at that point any llvm-3.5 compatability issues would be sorted out upstream already for us. * In any case, my modifications to ghc to make it explicitly use a single version of llvm are the right thing to do, and a necessary first step. -- see shy jo
signature.asc
Description: Digital signature
