Heads up: F21 LLVM rebase

Michael DePaulo mikedep333 at gmail.com
Fri Dec 12 22:04:53 UTC 2014

On Fri, Dec 12, 2014 at 10:30 AM, Adam Jackson <ajax at redhat.com> wrote:
> On Fri, 2014-12-12 at 13:01 +0100, Marcin Juszkiewicz wrote:
>> W dniu 11.12.2014 o 18:16, Adam Jackson pisze:
>> > I've started staging an LLVM 3.5 rebase in F21.  I hope to have
>> > everything built by this Friday and the update available in testing
>> > by Monday.  Test feedback would be particularly appreciated on
>> > secondary arches and radeonsi 3D hardware.
>> Can someone explain to me (like to total idiot would be best) why after
>> release of stable version developers start to update components? IMHO
>> time for it was during F21 development and now work should concentrate
>> on F22 with just stable fixes for released versions.
> We need to update Mesa in stable releases for hardware enablement,
> otherwise people buy new hardware and can't use 3D and then Fedora
> sucks.  Mesa and LLVM are sufficiently closely entwined these days that
> eventually I can't build fully-featured Mesa without updating LLVM.
> This isn't the first time the llvm soname has changed within a release,
> in fact it's happened at least once per release since F18 afaict.
> Yes, it's disruptive, it's a gigantic pain in the ass, I don't enjoy
> doing it at all.  llvm upstream seem to have no concept of consumable
> interface design, so at this point around half of the llvm-using
> components in Fedora have to be built from the same srpm as llvm itself;
> most of them are only build-tested with clang, so I also get the joy of
> trying to port them to gcc.  All this without having much working
> knowledge of C++, on account of how I want to be able to look myself in
> the mirror in the morning without crying.  I'm not a toolchain hacker.
> I want not to work on this crap.
> But either someone does it, or Mesa goes stale, so it's gotta get done.
> On the flip side, by synchronizing llvm (and Mesa and friends) across
> releases, graphics devel has more time to spend on _everyone_'s issues,
> because we don't have to waste time tracking which bug was fixed in
> which branch.
> In this particular case I had _wanted_ to get 3.5 into F21 gold in the
> first place [1], since it's sort of mandatory to make ppc64le actually
> work.  The timing didn't quite work out, so it happens in updates
> instead.  Sorry about that, life doesn't always admit pretty solutions.
> [1] - https://lists.fedoraproject.org/pipermail/devel/2014-October/203463.html
> - ajax

1st, thank you for the contributions you make.

I too come from an Ubuntu/Debian background. Like other major pieces
of software, Ubuntu and Debian both make multiple 2.x or 3.x versions
of LLVM available for each release of  their OS. They do the
1. The major version is specified in the package name. For example,
"llvm-3.4" and "llvm-3.5" are the names of separate packages. The
actual package versions are like "3.4.2-13" & "3.5-6" respectively

2. The package "llvm" is a small package that depends on the
recommended major version for developers. For example, in Jessie, 3.5
is the recommended major version, and Jessie "llvm" contains symlinks
such as:
/usr/bin/llvm-extract -> /usr/bin/llvm-extract-3.5

Would Fedora permit someone like myself to contribute an LLVM
packaging scheme like that?


More information about the devel mailing list