-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 2020-05-19 at 07:03 -0500, Richard Shaw wrote:
So I get the whole Fedora first, but...
FreeCAD has been in a terrible state in Fedora for a couple of years
and I've nearly given up on trying to maintain the package a few
The previous battle was with the Coin3D stack which finally got
Coin4 in f32 (then Rawhide). I constantly got bugs submitted that
was broken in f31 and my answer was, "Be patient it'll finally be
Fedora 32 where the Coin3D stack is updated!".
Was this caused by upgrade of Coin3D stack in Fedora? I did not see any
Change Proposal for this in F32, so probably this should have been
better communicated / tested?
However, that was a lie. Unintentional, but a lie nonetheless.
Fedora 32 releases and I'm enthusiastic that freecad will finally be
*fixed*! And then I get my first BZ, now PySide2 is broken... Why?
Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8.
instead of asking ourselves, "should we push in the VERY latest
hope it's ok?", we just patch the build system to accept it anyway
for the best.
I think pushing for latest Python is the best approach for Fedora, but
I agree that this is unfortunate. However, it is not only about Python,
we also have GCC / glibc and others which are built from master branch
in the beginning of Rawhide so that it gets some testing.
Qt (et all) is a pretty organized upstream, so when asked about
support in 5.13.x, they said, "Nope. Wait for 5.14.x."
I think what could help here is to make sure that list of specific
applications / framework works with new version of Python when Python
team is upgrading it. If we are not pushing upstream to support new
version of Python, it will happen but much later.
Also we are not pushing for new versions of Python in stable releases,
so at least that is not affected.
What good does that do me? At the time it wasn't released, and
only Rawhide got it. And I get why. Updating the whole Qt stack and
rebuilding all the dependencies is pretty a pretty painful process.
I think we should get people who maintain Qt on board when updating
Python so that they make sure to backport necessary patches from
upstream when we upgrade Python.
So all that to say, we seem to be taking "Fedora First" to
going to update regardless of what it breaks.
All this is about balance, if it breaks only 1% of applications, but
helps 40% of applications (all numbers are random here from my head) it
makes sense to upgrade. Not breaking even 1% of applications is what
RHEL is supposed to solve, not Fedora.
This is a little more ranty that I intended it to be, and no, I'm
to go research and paste a bunch of BZ urls, this isn't about asking
help, it's more policy related.
Hell, I still have one project that all but refuses to update to
Fortuantly a user found a github project that had the needed patches
backported from 5.14.x! Fingers crossed freecad will work again for
than 5 seconds.
That would be cool!
Now I'm being told PySide2 doesn't build with Python 3.9
not surprised! It's not even released yet. I can (and will) inform
upstream. But what do you think their answer is going to be? Wait for
Ask upstream to always test with develop version of Python, I believe
that services like Travis CI have 3.9-dev prepared so that they can
test early and adopt.
Meanwhile, if they can just link all relevant fixes - just backport
them in Rawhide.
Ok, rant over.
Thank you for sharing your experience here.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----