The names `%bcond_with` and `%bcond_without` are based the inner workings of
the macros. They describe the inverse of their default; anecdotal evidence
sugests that this is quite confusing in practice. I personally always have to
stop and think when using/reviewing them.
This PR adds the macro
OK, I'll fold the comments into the Markdown docs.
--
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/1520#issuecomment-769807126___
@encukou commented on this pull request.
> ## Check whether an option is enabled or disabled
-To define `BuildRequires` depending on the command-line switch, you can use the
-`%{with foo}` macro:
+To make parts of the spec file conditional depending on the command-line
+switch, you can use th
@encukou pushed 1 commit.
9218cbdeef7a9839d7a7b1033d5325c3e0444d34 Fix typos in docs
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1520/files/831de9ed06a9e33957074105693b04226d636b21..9218cbdeef7a9839
@encukou pushed 1 commit.
e0d581b9b7c47b1817700cc35ea99a21963a97df Add newly added file to Makefile.am
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1520/files/9218cbdeef7a9839d7a7b1033d5325c3e0444d34
All info from the comments in the macro file is in the docs, except that:
> When checking conditions: never use `without_foo`, `_with_foo` nor
> `_without_foo`, only `with_foo`.
contradics with the [Pass it to
%configure](https://github.com/rpm-software-management/rpm/blob/master/doc/manual/con
@encukou pushed 1 commit.
eef816619d9bd225e9768aa81990fa6b36e387e8 Doc nit
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1520/files/3510e485cd647bdf211097365531af8511d90ddf..eef816619d9bd225e9768aa819
@encukou commented on this pull request.
> @@ -76,47 +76,25 @@
%defined() %{expand:%%{?%{1}:1}%%{!?%{1}:0}}
%undefined() %{expand:%%{?%{1}:0}%%{!?%{1}:1}}
-# Shorthand for %{defined with_...}
+# Handle conditional builds.
+# (see 'conditionalbuilds' in the manual)
+#
+# Internally, the
@hroncok I gave you access to my fork in case you want to take this in the next
few weeks. I probably won't have free cycles soon.
--
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/rp
This hit us again in https://bugzilla.redhat.com/show_bug.cgi?id=1930066
We'dlike to patch Sphinx (a documentation generator) to default to
offline-friendly documentation when building RPMs. But, this would mean that
the dependency on `mathjax` (a rather large Javascript module for displaying
e
@encukou commented on this pull request.
> @@ -76,47 +76,25 @@
%defined() %{expand:%%{?%{1}:1}%%{!?%{1}:0}}
%undefined() %{expand:%%{?%{1}:0}%%{!?%{1}:1}}
-# Shorthand for %{defined with_...}
+# Handle conditional builds.
+# (see 'conditionalbuilds' in the manual)
+#
+# Internally, the
I got back to this; all issues except the nested `%{expand:..}` should be
addressed.
--
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/1520#issuecomment-912633112
Hello,
RPM is typically built/installed as a system component, and the Python bindings
are tied to a particular minor (3.x) version of Python. Using the bindings with
other Python versions is difficult.
I'd like to solve the issue for `rpm` and similar bindings to “system”
packages. There's a fe
OK!
A proof of concept is [at my
fork](https://github.com/rpm-software-management/rpm/compare/master...encukou:rpm:python-stable-abi-poc).
The diff is big but most changes are rather mechanical. Read below for context.
How would you prefer me to contribute this? Polish it and submit one big PR,
I'm only asking to drop Python 3.1.
With the change, a single Stable ABI `.so` would support Python 3.10+ (or even
3.7+), but for older Pythons you could still build version-specific extensions,
like now.
Sorry I didn't make that easy to skim.
--
Reply to this email directly or view it on Git
> AIUI there's no functionality change, except for the init-only-once part?
Init once, dropping 3.1, and mutable type objects (the PoC uses
[`Py_TPFLAGS_IMMUTABLETYPE`](https://docs.python.org/3/c-api/typeobj.html#Py_TPFLAGS_IMMUTABLETYPE`)
but that's 3.10+ only).
And the unknown unknowns – I've
Is putting something like `%bcond foo 0%{?default_foo}` in the spec file not an
option?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1453186692
You are receiving this because you are subscribed to this thread.
Messag
Yup, too busy, mostly with a certain security issue.
I've actually picked this up again just last week (but left for a conference on
Thursday). It's now on the top of my TODO list :)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2345
These are the changes needed to use Python's stable ABI. This allows the
extension to be used without recompilation with multiple versions of Python
(from 3.7 until an ABI break).
Hack to make this easier:
- type objects are allocated when the module loads, stored in global pointers,
and never
The PR is up at https://github.com/rpm-software-management/rpm/pull/2674.
I'd appreciate help with CMake -- I'm not familiar with it and I don't exactly
know what I want from it in terms of versions and options :)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
I dialed up my Python debug settings, and got complaints about unclosed files
on stderr, whis caused tests to fail for me.
This properly closes all the files the Python tests `open`s.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm
Would this be a better wording?
> differs from a package that has /bin/sh in the %files list. For example, rpm
> will not remove `/bin/sh` when the package is uninstalled.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2673#issuecomm
> Requiring Python >= 3.7 is not a problem, I'm just curious as to what makes
> that particular version special.
[`PySlice_GetIndicesEx`](https://docs.python.org/3/c-api/slice.html#c.PySlice_GetIndicesEx)
uses a deprecated implementation (on all Python versions) if ABI compatibility
with 3.6 is
@encukou pushed 2 commits.
69db01e2c2a6321cd3df9b8b60c5fb9f407a039b Fix comment style
ccc3af9c97ba635f8ef66aad4333c3ad0f617bcc Select Python 3.7+ stable ABI
"manually" if CMake doesn't support it
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/1da65d26b64c
@encukou pushed 1 commit.
1f41d7e4513b0f5c3dfbd7f1f19e60774bd02b15 Select Python 3.7+ stable ABI
"manually" if CMake doesn't support it
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/ccc3af9c97ba635f8ef66aad4333c3ad0f617bcc..1f41d7e4513b0f5c3dfbd7f1f19e607
Would this work?
- CMake 3.26+ default:
- Build for stable ABI using CMake's mechanism
- Needs Python 3.7+
- Older CMake, and builds with `-DENABLE_PYTHON_SABI=OFF`:
- Needs Python 3.2+
- On Python 3.7+, build for stable ABI "manually" by defining
(I haven't tested, I'm still not sure
@encukou pushed 2 commits.
6394b1d583a3dae612c49baa6ad28b8b555d410b Fix comment style
8343d71e5043713a38daf3436a7e489134421acf Python Stable ABI: Build for Stable
ABI, require Python 3.7+
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2674/files/1f41d7e4513b0f5c3dfb
@encukou pushed 2 commits.
9c96b7882d7db454818c8ed8a9953e91b7b9ac15 Python stable ABI: Define
Py_TPFLAGS_IMMUTABLETYPE as no-op if missing
efdd3ede6c11938d0252f9125fabf6326b349614 Python Stable ABI: Build for Stable
ABI, require Python 3.7+
--
View it on GitHub:
https://github.com/rpm-softwa
I did that, and I also updated the version in the `INSTALL` file.
I didn't test this build config with all the Python versions, and I won't get
to that next week, but will do it the week of Oct 16. I find any issues, I can
open a fixup PR.
--
Reply to this email directly or view it on GitHub:
> the module, and its types, can only be initialized once per process
For reference, the Python version where this limitation can be lifted
*relatively easily* is 3.10 (which adds API for type/module association, like
[PyType_GetModule](https://docs.python.org/3/c-api/type.html?highlight=pytype_
> We agree that using MIME type suffices like "*.py" as a selector is
> intrinsically flawed.
Yes.
> Equally flawed is, say, assuming that Python is always installed on prefixed
> paths that match the pattern "/usr/lib(64)?/", or in, say, a sub directory
> "pythonX.Y" implying that /usr/bin/py
> But adding packager driven macro enabler/disabler infrastructure instead of
> changing a script seems a grossly ignorant hack (to me).
This shouldn't be (widely) used by packagers.
The main part of this PR is that it *allows* skipping the problematic part of
the script (while still running the
Thanks for the mention. I have nothing better to contribute now. I'm planning
to submit a well-tested, strictly standard-based implementation, but It looks
like I'll not get to complete it this year.
(Please don't read that as an attack! This change is better than the status
quo, and perfect is
> https://github.com/gordonmessmer/convert-440/blob/master/convert-pep440.py
Wow! That looks great!
I started writing something similar, but ran into a lack of tests – I can't
hold all the details in my head alone.
> For example, I don't know what you have in mind when you say "strictly
> stand
I won't be able to think through all the edge cases soon to give you "this
doesn't work, because..." kind of feedback. But "reverse requirements" do look
viable.
I guess my question is: when can this be done, relative to proper support for
dynamic subpackages?
* if later, or just a little sooner
My old suggestion was `%bcond `, with numeric "default" (zero
for false).
Aside from "inheritance", it might be used instead of
`%bcond_with`/`%bcond_without`. (Whenever I try to choose one, I have to stop
and think which one will give me the right default. I don't think I'm alone in
that.)
``
36 matches
Mail list logo
