On 06. 08. 19 0:58, Kevin Kofler wrote:
Miro Hrončok wrote:
mkdir hackpath
ln -s %{__python2} hackpath/python
export PATH=$(pwd)/hackpath:$PATH
These will work as long as nothing hardcodes "#!/usr/bin/python". So far, I
only found the proper "#!/usr/bin/env python" (see now why it is the right
thing to do, even if Fedora packaging guidelines claim otherwise?), but I
haven't scanned all files yet.
Using env shebang is the right thing to do for an upstream project, yes. I've
never said otherwise.
The custom PATH approach is definitely the first one I'd try.
That's what I have been using as well.
Let me kindly remind you that using /usr/bin/python is against the
packaging guidelines since Fedora 29. Making assumptions about the
versions of /usr/bin/python has been forbidden since I don't know when.
Your packaging guidelines cannot dictate what upstream build systems use, no
matter how much wishful thinking you apply in your shiny fantasy world. And
even if they could, they could still not go back in time and magically fix
legacy software that predates your guidelines by years.
No you cannot. But we can adjust the packages we ship before we do so.
I think the fallout is going to be even worse outside of the Fedora Koji
sandbox (though then again, there, the local admin can just install their
own python2-unversioned-command package or even just add an unpackaged
/usr/bin/python → python2 symlink – I bet many will).
And that completely fine. Another reason why no Fedora packaged software should
ever use /usr/bin/python.
The python2-unversioned-command would be pulled by users when they install
/usr/bin/python. We don't want that. Python 2 is deprecated and will be
removed, this was communicated loudly and handled slowly for years.
It would not, if you ensure python-unversioned-command gets installed by
default and Conflicts: python2-unversioned-command.
That is most likely correct. Apologies. (It still doesn't make me want that
package at all but that single argument was not true.)
And even if the users don't have it installed yet, why would
python2-unversioned-command get preferred over python-unversioned-command by
DNF?
Why not? Unless some hackery-suggesty-trickery is used, the preferred package is
an implementation detail.
If you need to keep Qt 4 qtwebkit in Fedora 32 and it cannot be built with
Python 3 with any reasonable effort, you will need a FESCo exception
anyway.
This is even more ridiculous.
I don't see why Python 2 cannot be held to the same standards of providing
compatibility support as long as applications need it as Qt 3 and Qt 4. We
still ship Qt 3 just fine (and backport security fixes when needed), more
than 11 years after the last upstream release! (And Qt 3 does not depend on
Python 2. ;-) ) Your strict unwillingness to do the same for Python 2 is
creating huge problems for a large class of packagers and end users alike.
Do you want to maintain the stack? We clearly communicated the following over
the years:
"If someone steps up to maintain Python 2 (including the full ecosystem of
packages now in Fedora), they can decide to discontinue removing packages,
revert the Change, or come up with another plan. (Note that in this case,
current maintainers will most likely orphan many fundamental python2 packages.)"
This offer is still valid. I certainly don't want to maintain it and none of the
others present Python 2 maintainers either. Note that we will still maintain the
interpreter for our users. We will simply not maintain it for hundreds of legacy
packages that somebody packaged years ago and are dead otherwise. Requiring a
FESCo exception is a way to ensure we only support it for the packages where it
benefits the project as a whole (might very well be the case for Qt 4, IDK).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
