On Mon, Jan 15, 2018 at 3:06 AM, Panu Matilainen <pmatilai(a)redhat.com> wrote:
> On 01/14/2018 04:46 PM, Neal Gompa wrote:
>> On Sun, Jan 14, 2018 at 7:22 AM, Igor Gnatenko
>> <ignatenkobrain(a)fedoraproject.org> wrote:
>>> On Thu, 2018-01-11 at 10:37 -0500, Neal Gompa wrote:
>>>> As I was looking at the rpm.spec and fixing up a small bit of the
>>>> build for the Python bindings, it occurred to me that we have left
>>>> python-rpm-generators out of sync with rpm.
>>>> I'm wondering if it even makes sense to keep that as a separate source
>>>> package, and instead build the python3-rpm-generators subpackage from
>>>> the main rpm package. I'd much rather do that as it makes it much
>>>> easier to keep everything in sync.
>>>> We inherited the split from Fedora, who did it for their failed
>>>> modularity effort to try to make a base system environment that was
>>>> only C and shell but also contain the rpm-build package (I didn't say
>>>> it made sense...). From the point of view of Mageia, who is unlikely
>>>> to attempt what Fedora is doing, I'm not sure there's a particular
>>>> value in doing so. I was not even particularly enthused about this
>>>> when Fedora did it...
>>>> Insofar as bytecompilation issues are concerned, we should probably
>>>> rename the file on install to not have the .py suffix, so that the
>>>> Python interpreter doesn't consider it as something to bytecompile.
>>>> That will allow us to avoid the issues that necessitate python -> rpm
>>>> -> python rebuilds.
>>>> What do you all think?
>>> To be honest, I would like to separate even upstream to its own
>>> repository. I
>>> don't think it makes sense to keep it part of RPM itself.
>>> CCing python SIG and RPM maintainers for their feedback.
>>> - --
>>> - -Igor Gnatenko
>> If we were going to do something like that, I'd actually like to have
>> a repository in rpm-software-management where we can contribute
>> dependency generators of all kinds beyond the basic ones included in
>> RPM for everyone to use. It makes no sense for people to reinvent the
>> same things over and over simply because they didn't know it was
>> already written somewhere.
> Yes, that's kinda been the idea ever since making it possible in rpm 4.9.x,
> and which is why I've encouraged people splitting their generators out of
> main rpm package. It's just the common upstream part that is lacking...
Now that we have the GitHub organization, I don't see why we couldn't
have a repository that could serve this purpose.
Don't get me wrong, I think there needs to be a basic set of
dependency generators in the main RPM repo. The current ones are fine
in the main repository, but there's *a lot* of generators out there,
written by Fedora, SUSE, Mageia, and others. Putting them somewhere in
one place can help us reduce the duplication and ensure things are
consistent, as well as helping to improve the quality of those
真実はいつも一つ！/ Always, there's only one truth!
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 2018-01-11 at 10:37 -0500, Neal Gompa wrote:
> As I was looking at the rpm.spec and fixing up a small bit of the
> build for the Python bindings, it occurred to me that we have left
> python-rpm-generators out of sync with rpm.
> I'm wondering if it even makes sense to keep that as a separate source
> package, and instead build the python3-rpm-generators subpackage from
> the main rpm package. I'd much rather do that as it makes it much
> easier to keep everything in sync.
> We inherited the split from Fedora, who did it for their failed
> modularity effort to try to make a base system environment that was
> only C and shell but also contain the rpm-build package (I didn't say
> it made sense...). From the point of view of Mageia, who is unlikely
> to attempt what Fedora is doing, I'm not sure there's a particular
> value in doing so. I was not even particularly enthused about this
> when Fedora did it...
> Insofar as bytecompilation issues are concerned, we should probably
> rename the file on install to not have the .py suffix, so that the
> Python interpreter doesn't consider it as something to bytecompile.
> That will allow us to avoid the issues that necessitate python -> rpm
> -> python rebuilds.
> What do you all think?
To be honest, I would like to separate even upstream to its own repository. I
don't think it makes sense to keep it part of RPM itself.
CCing python SIG and RPM maintainers for their feedback.
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
-------- Forwarded Message --------
Subject: F28 Self Contained Change: Avoid /usr/bin/python in RPM build
Date: Tue, 9 Jan 2018 20:13:58 +0100
From: Jan Kurik <jkurik(a)redhat.com>
Reply-To: Development discussions related to Fedora
To: Development discussions related to Fedora
= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build =
* Petr Viktorin <python-devel at lists.fedoraproject.org>
* Miro Hrončok <python-devel at lists.fedoraproject.org>
Deprecate, and later disable, running /usr/bin/python (as opposed to
/usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to
build (with the failure message providing an easy workaround).
== Detailed Description ==
=== Motivation ===
Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout Fedora.
This is a multi-release effort tracked in Python SIG's "Finalizing
Fedora Switch to Python3" document.
This page describes a very focused subset of it.
Renaming packages (and associated changes to, for example, "Requires:"
directives) is relatively straightforward, but making all
Fedora-provided code avoid /usr/bin/python (as opposed to
/usr/bin/python2) is both harder to achieve and harder to keep track
We would like to start deprecating /usr/bin/python (as opposed to
/usr/bin/python2) at RPM build time.
RPM build is a controlled environment: changes to it will not be felt
by end users, breakages are almost immediately visible, and output of
Koji builds can be nicely tracked and analyzed.
=== Specification ===
Python 2, when called as python or /usr/bin/python at RPM build time
(as identified by the RPM_BUILD_ROOT environment variable), will print
a deprecation warning to stderr. (Any program invoked during build
that invokes /usr/bin/python will cause this warning as well.)
A new Taskotron check will be implemented to look for this warning and
fail if it's found.
We will look at the Taskotron results and work with packagers to
switch to update the affected packages. (We'll look at the results to
determine if we'll use automated pull requests, mass bug filing, or
The warning itself may cause some packages to fail to build, for
example if a test relies on exact stderr contents.
For these cases, it will be possible to turn the warning off using an
environment variable, but we ask packagers that use of this workaround
is tracked in Bugzilla. See Opt-Out below.
After all packages that BuildRequire python2 are re-built with this
check passing, python will be switched to fail after printing the
The warning will not be effective if stderr output is hidden. So,
after switching /usr/bin/python to fail, some packages may start
failing to build. We will work with the packagers to fix these. (We'll
look at results from the "warnings phase" to see how proactive we'll
need to be here.)
The warning text will be:
DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
If you cannot make the switch now, please follow instructions at
(Using the Wiki link allows us to easily revise the instructions.)
=== Quick Opt-Out ===
In case switching to /usr/bin/python2 or /usr/bin/python3 is
non-trivial, do these two things:
* Set the environment variable
DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling
* File a Bugzilla, and make it block our tracking bug (XXX - link)
All such bugs will need to be fixed before we make /usr/bin/python fail
== Scope ==
* Proposal owners:
Patch python2, write the Taskotron check, deal with warnings and failures.
* Other developers:
Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM
build time (with help from Proposal owners if needed). Also tools that
are invoked during build time of other packages that themselves use
/usr/bin/python will need to be fixed.
* Release engineering:
Note: Depending on the timing, separate targeted rebuilds may be
needed, but we can do these as Proven Packagers, no side-tags are
* List of deliverables:
* Policies and guidelines:
Already existing "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
* Trademark approval:
N/A (not needed for this Change)
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org