Backporting LLVM 3.1 for Fedora 17

[Kevin Kofler]

Adam Jackson wrote:
> This would actually make it easier to keep updated Mesa in older
> releases.  Right now if we backport Mesa 9 to F17 we'd have to disable
> the radeonsi driver as it requires >= llvm 3.1.

Good to hear that you're also in favor of this (since some people had voiced 
concerns about upgrading the main dependency of llvmpipe).

> That said, llvm consumers are difficult to keep in sync with llvm
> anyway.  Many llvm projects seem like they pick a point release to build
> against and then never get updated when the ABI changes.  If we do this
> we might want to start by building compat-llvm30 for the libraries and
> migrating the consumers independently afterwards.  It'd be fine if that
> compat package only lived for the one release that needs it (ie no
> compat-llvm30 in F18 or later, apps that aren't ported get
> deadpackaged), but at least that way we could avoid breaking llvm apps
> in F17 updates that worked in F17 gold.

I'd prefer avoiding the compat package if at all possible, IMHO we should 
consider it only if some stuff really cannot build with the new version (but 
then it would have broken in Rawhide as well, wouldn't it?), because 
otherwise, if the app ends up linking in OpenGL, say hello to symbol 
conflicts. (We've had our fun with that issue with OpenGTL in the past, 
where Krita was linking both libGL and OpenGTL and they were using different 
statically-linked LLVM builds, leading to Krita crashes. Thankfully, this 
has been fixed, but if LLVM is upgraded in a release, a matching OpenGTL 
build will have to be included in the update group.)

> I'm aware that this isn't quite in line with the Fedora updates policy,
> but I consider that a bug in the policy.  I'd be happy to help draft
> policy amendments for this so we have a standard process.

In this case, upgrading seems to be the only reasonable way to ship a 
working LLVM/Clang stack.

        Kevin Kofler