Resurrecting the FEniCS packaging effort
by Jason L Tibbitts III
So a while back (i.e. maybe six years ago) there was an effort ongoing
to get the FEniCS suite (https://fenicsproject.org/) packaged properly
in Fedora. It appears that effort rolled up a few years ago without
being completed, though a few of the required packages are still in the
Now some researchers here are wanting to use FEniCS and they're
expecting me to make it work for them. Currently they're trying to
install it through that mess that is Anadonda (but not that Anaconda,
the other one that stole the name). It seems this comes in as several
gigabytes of precompiled crap including its own C compiler, copies of
system libraries like libibstcd++ and boost, its own version of Qt, and
other horrific things I didn't even try to delve into. Why anyone
thought this was a good idea, I'll never know, but there it is.
So, I'd like to look into what it would take to get things going again.
But the problem is that I know nothing about FEniCS and will certainly
never use the software myself, which makes me something less than a
perfect candidate for a maintainer. Is there anyone else here that
might be interested in having this software around in Fedora who might
be able to help with maintainership?
Here's a rundown on the current status of the FEniCS-related packages:
* python-ufl, python-instant and python-fiat are currently in the
distribution (owned by Fabian Affolter) but about 2.5 years out of
* python-ufc was in the distribution but has been orphaned and retired
since 2015. But I don't think it's needed currently.
* python-viper isn't actually needed, I guess.
* python-ffc and dolfin never completed review.
* python-dijitso appears to be a new dependency.
* I'm not sure if my folks need mshr. It (of course) seems to bundle
CGAL and Tetgen, both of which are already packaged.
I don't yet know if any new requirements have shown up in the past few
years. But if not, it looks like the effort involved is updating three
packages and then getting three new packages made and into the
distribution. Fortunately there are existing specfiles to crib from for
two of those three (and for the most part, the python modules aren't
terrible to package in any case).
So, is anyone interested in chipping in? Even if it's just with package
reviews, that could be a great help.
4 years, 6 months