Closed #508.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/508#event-2157511405___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
After discussing this at length with @ffesti, these Python macros and helpers
dropped in commit ba85c95963f9b62f237c0442f6b5aca3e355fa83, along with Perl and
PHP helpers, see commit message for rationale.
Thanks for initiating the avalanche @ignatenkobrain :wink:
--
You are receiving this bec
However, unlike most newer languages, the ones we have macros for in here are
also ones where rpm includes code for in its source tree.
Since we have Python bindings, I'd rather have us keep those macros in here...
--
You are receiving this because you are subscribed to this thread.
Reply to th
The most compelling argument for dropping is that such macros should've never
been added to rpm in the first place, ditto for similar perl etc macros. They
belong to the corresponding language(s), as has been done with all the newer
languages appearing on the scene.
--
You are receiving this b
It is already the distributor's problem, since they have to build rpm and tell
it what the Python interpreter is.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/508#issuec
...however there is the point that maybe this really *should* be somebody
else's problem, and the python 2 -> 3 transition is probably the best chance
we're ever going to get for making that so...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
I tend to agree with @Conan-Kudo there: Python 2 is being phased out with
increasing force, and once it's gone it'd be just stupid for %__python to be
anything else than Python 3. So the forward-looking solution is a), and all the
others are "make it somebody elses problem" in one way or the oth
@hroncok That doesn't preclude the default Python being set. I (ab)use this
fact for Pagure packaging in Fedora already.
And keep in mind that in exactly 1 year and 2 months, `/usr/bin/python` will
mean _only_ Python 3 anyway.
This is much ado about nothing.
--
You are receiving this because
This is very helpful for spec reuse. You can use python_helpres anywhere in the
spec, but at one place, just define %__python as needed (e.g. /usr/bin/python
on RHEL7, /usr/bin/python3 on Fedora, %{__python3} on RHEL8, /usr/bin/pypy in
your custom repo...).
--
You are receiving this because yo
Red Hat's indecision aside, pretty much everyone else knows how they're going
to have "default Python". And don't we have a `@__PYTHON@` substitution anyway?
It gets filled in with whatever is detected for the interpreter.
If you want to be fancy, just make it if `@__PYTHON@` isn't detected at b
Yes, but add error handling to python_foo helpers (e.g. if I set %__python to
/usr/bin/false or a not existing file).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/508#is
So you're suggesting we remove just the %__python macro, (or define as an
error), but leave the python_foo helpers around?
That'd account for option d) basically.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gith
I think that %__python should be configurable anything (that meets a certain
API, so
%python_sitearch etc. can work). However I don't think it needs a default.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.
> What does "default python" even mean and why does RPM need to care?
Exactly. Nobody knows wtf %__python is supposed to mean these days. Yet rpm
should somehow know what to with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
What does "default python" even mean and why does RPM need to care?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/508#issuecomment-440611034___
The fundamental problem is that the Python 3 transition has mutilated the once
simple Python landscape into something barely recognizable. Rpm cannot possibly
know what the "default python" is when such a thing no longer exists -
/usr/bin/python could point to anything at all or not even exist,
Well, just removing those is not sufficient. Unless they are deleted they need
to move somewhere else. Either create an rpm-macros-python project here on GH
or move them to rpm-extras.
Yes, you probably have just added them to some package in your distribution.
But I'd rather keep a centralized
The whole idea that absolute paths need to be provided as macros to be expanded
in spec files has been unnecessary since POSIX was invented and widely deployed.
When was the last time you felt the need to write a shell script that used
absolute paths for common system programs? The entire reason
Conan-Kudo requested changes on this pull request.
NAK. These are relied on in RPM-managed systems to provide an interface for the
"default" Python.
For example, these are used in OpenMandriva for Python 3, since Python 3 is the
default Python.
--
You are receiving this because you are subs
Those belong to python, not RPM.
Signed-off-by: Igor Gnatenko
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/508
-- Commit Summary --
* macros: drop python macro
-- File Changes --
M macros.in (8)
M scripts/Make
20 matches
Mail list logo
