Conan-Kudo approved this pull request.
Looks good to me and covers rich dep versions now!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain pushed 1 commit.
f9f83a9 build: simplify logic of checking modifiers in dependencies
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
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
Also I reordered it for ease of cherry-picking to stable branches.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe I pushed commit which fixes that issue.
@pmatilai @ffesti I believe that we should backport it to old versions, because
it is a bug.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain pushed 2 commits.
26410a6 build: make haveRichDep aware of other fields allowed to have them
998c1b8 build: check rich dependencies for special characters
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
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
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:
...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
@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
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
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:
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:
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:
> 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:
18 matches
Mail list logo
