The status of Blender

So after my recent complaints on the way Blender is packaged upstream, it’s a probably a good idea to see what the current status on the topic is.

First of all, upstream has been at least discussing how to deal with these kind of complains: while some commenters complained about leaving Gentoo because of our decision of not bumping to 2.65a (yet), with the idea that it’d be much easier to have Blender on Debian, Arch Linux or whatever else, it turns out that Gentoo was not alone having trouble with Blender, and indeed Matteo asked our help with patching at least for libav-9 support.

For what concerns Gentoo, while I keep getting bugs requesting an update to version 2.65a, I’ve been basically closing them every time, as none seem to care about getting it right — and I really don’t want to get a crappy ebuild in, as I’d be the one taking the pieces anyway. Mostly, what we need is a version of Blender ebuild that does use CMake, but also does not use the bundled libraries for all the code we have in the system already. The main issue here is Bullet, which requires a version bump, possibly with a pre-release snapshot of 2.82, due to the patches that are applied on top of the copy that comes with Blender.

Today I actually had to shoot down a request for a live ebuild; due to the quantity of patches that we end up having to apply, we’re not going to get a live ebuild, full stop.

Unfortunately, this also left us for a long time to deal with the old, buggy, and bitrotting version 2.49b which was marked stable. That stopped today as, with the agreement of at least some of the arch team members, I masked Blender altogether and got rid of version 2.49b-r2 and its patches from the tree. If you do want to use Blender now, you’ve got to unmask it. While this could be considered like dropping the ball on it, it’s just making it explicit that we haven’t been supporting version 2.49b for a long time already.

No, don’t ask for it to be re-added slotted. Upstream is not maintaining a 2.4x branch, so we won’t be doing that either.

So right now if you want to help, start by preparing (upstreamable, or even better, upstreamed) patches that allows to select with CMake the use of system libraries for most of the bundled ones. Another thing that would be very useful at this point would be a separate ebuild for libmv, even with the bundled libraries to start with, so that would at least stop the multi-level madness and we would end up with good old single-level bundled libraries.