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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
