Miro Hrončok wrote:
> Maintaining legacy software is impractical. Use a hack. There are some
> options:
>
> 1) carefully sed python for python2
This assumes I find the files to sed first. They are spread throughout the
build system. They may or may not all have .py extensions. And blindly
running sed on all files may have other side effects due to messing up time
stamps.
> 2) define a function, export it:
>
> function python() { python2 "$@"; }
> export -f python
>
> 3) define a custom PATH:
>
> 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.
The custom PATH approach is definitely the first one I'd try.
> 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.
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).
> 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.
And even if the users don't have it installed yet, why would
python2-unversioned-command get preferred over python-unversioned-command by
DNF?
> 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.
Kevin Kofler
_______________________________________________
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
