-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Richard,
On Tue, 2020-05-19 at 07:03 -0500, Richard Shaw wrote:
> So I get the whole Fedora first, but...
>
> Backstory:
>
> FreeCAD has been in a terrible state in Fedora for a couple of years
> now
> and I've nearly given up on trying to maintain the package a few
> times now.
> The previous battle was with the Coin3D stack which finally got
> updated to
> Coin4 in f32 (then Rawhide). I constantly got bugs submitted that
> freecad
> was broken in f31 and my answer was, "Be patient it'll finally be
> fixed in
> 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?
No, this was just backstory. The Coin3D v4 stack was required for FreeCAD but up until Fedora 32, Only the v3 stack was available., It was only updated in rawhide (f32 at the time).
> 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.
> But
> instead of asking ourselves, "should we push in the VERY latest
> Python and
> hope it's ok?", we just patch the build system to accept it anyway
> and hope
> 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.
GCC affects a lot more packages and problems tend to get fix pretty quickly.
> Qt (et all) is a pretty organized upstream, so when asked about
> Python 3.8
> 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.
This is where I was going even if I didn't mention it explicitly. I think we need to be more organized in how things are updated and try to keep a list (somehow) of libraries (more so than end user binaries) that may not work with the latest and greatest.
> What good does that do me? At the time it wasn't released, and once
> it was
> 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.
It didn't affect Qt5 AFAIK, just the python bindings (PySide2), but as far as people, it's mostly Rex and I help where I can.
> So all that to say, we seem to be taking "Fedora First" to mean,
> we're
> 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.
I don't think that's quite a good rationale, breaking 1% of apps is unfortunate, breaking 1 framework is bad.
> Now I'm being told PySide2 doesn't build with Python 3.9 pre-release.
> I'm
> 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
> 5.15?
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.
Those more familiar with the changes implemented could do a better job at helping me inform upstream (and maybe help provide solutions?) But I think that comes with being more organized in how to do major component updates.
Thanks,
Richard