[Rpm-maint] [rpm-software-management/rpm] Refactor %__file_lineno management into an auxiliary macro (PR #2746)
Now that we can, just define __file_lineno as an auxiliary macro that only does any work in the rare case where an error or warning occurred. This saves an enormous amount of huffing and puffing defining and undefining macros that are not used at all in the normal paths, on every rpm startup and spec parse. Technically we could use a common macro function for both but as theyre in separate libraries, this doesnt seem worth the few lines of saving. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2746 -- Commit Summary -- * Refactor %__file_lineno management into an auxiliary macro -- File Changes -- M build/parseSpec.c (25) M rpmio/macro.c (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2746.patch https://github.com/rpm-software-management/rpm/pull/2746.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2746 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)
A bug is a bug. The database needs to be as robust as anything else in rpm, security impact or no. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7495545 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)
I think @rhdesmond is in the situation of needing to process RPM databases that come from untrusted container images. These databases might be malicious and might try to exploit a bug in librpm to compromise the vulnerability scanner. Such a bug would arguably be out of scope for librpm because it would require root privileges to exploit, but in this case the root filesystem itself is untrusted. That’s why I suggested compiling librpm via WebAssembly, so that the impact of a compromise is limited. Without a trick like this, the only other approach that meets certain security requirements is to create a new virtual machine for each and every container being scanned, which is slow, uses lots of memory, and is incompatible with most cloud environments. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7491327 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error: invalid version: v"3" (but only in a a complex conditional) (Issue #1883)
I opened https://issues.redhat.com/browse/RHEL-15688 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1795068331 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error: invalid version: v"3" (but only in a a complex conditional) (Issue #1883)
I suppose you care because of RHEL 9. If that's the case, I suggest you open a RHEL 9 Jira. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1795002390 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error: invalid version: v"3" (but only in a a complex conditional) (Issue #1883)
4.16 fell out of upstream support with the release of 4.18, about a year ago. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1794994630 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error: invalid version: v"3" (but only in a a complex conditional) (Issue #1883)
A backport to 4.16 would be good too -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1794989036 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] What's the scope of --root (supposed to be)? (Discussion #2735)
`--macros` is problematic because it requires rewriting the entire path, most of which is fairly critical to normal operation. Basically rpm must always initialize itself with the macros from the same version, otherwise there's weird stuff can happen. Which means, rpm from the host must initialize with the macros from the host. For selective macro loading, --load=/some/path is much better alternative as this doesn't disrupt the normal macro path. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2735#discussioncomment-7487779 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Declarative build system support (#1087)
To recoup the very useful discussion and ideas from the now withdrawn draft PR: To make things properly declarative, overriding sections should not be a part of the plan at all. Instead there should be a way to declare independent build options one by one. And the "auto" in the name needs to go. What I'll be looking into now is: - `BuildSystem:` a singleton tag to declare the used build system for the package (tag name open to speculation still, `Build` is kinda tempting too) - `BuildOption(section):` a repeatable tag to declare options one by one to pass to the build system for a given section - `BuildOption:` without parentheses is equal to `BuildOption(conf)` which is by far the most common place needing options Support for a buildsystem is implemented by filling in the necessary macros for these sections. Said macros are responsible for passing the options from the BuildOption tags to the buildsystem as appropriate. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1087#issuecomment-1794476191 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
`BuildSystem`, `BuildType`, and `BuildOption(stage)` makes sense to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794452101 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
Ok, back to drawing board, now with a much nicer plan. Thanks for the very valuable feedback + ideas! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794447770 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
Closed #2620. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#event-10870320486 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
So... the conclusion from all the above rant is that there seems to be an actual design wanting to come out, that would probably be: `BuildOption(section):` to add options to the sections in a truly declarative fashion, and as a shortcut for the most common section, `BuildOption:` without the parentheses equals `BuildOption(conf):`. And call the whole thing by some different name. `BuildType:` perhaps, but that could have other uses (eg debug/production or such). `BuildSys:`, `BuildSystem:` or just even just `Build:` maybe. Thoughts welcome. Too bad there is no option to convert a PR into a discussion because that's what this resembles more now :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794362481 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
For a real-world examle of the 2-3 benefit, a typical bcond case from Fedora
rpm.spec:
Existing spec:
```
%bcond_without libarchive
[...]
%if %{with libarchive}
BuildRequires: libarchive-devel
%endif
[...]
%prep
cmake \
[...]
%{!?with_libarchive:-DWITH_ARCHIVE=OFF}\
```
Using a section override for %conf would be effectively unchanged from existing.
Spec tags:
```
%bcond_without libarchive
[...]
%if %{with libarchive}
BuildRequires: libarchive-devel
AutobuildOption(conf): -DWITH_ARCHIVE=OFF
%endif
```
3 would work equally well, just look a little out of place in middle of those
spec tags. In some other situation it may be surrounded by other macros and a
tag would look out of place, but that's probably an uncommon situation,
actually. The above also *screams* to be it `BuildOption(conf)` instead of this
auto-silliness.
Yet another observation is that configuration is the only place where one
typically expects "dozens" of options. For actual build/install stages, it's
usually more a matter of adding a flag / argument or two to override some
specific thing. Or, that's what I thought. Looking at the Fedora spec
collection, there's all manner of stuff being passed to both %make_build and
%make_install (and never mind everything that falls outside these). So while I
initially thought perhaps only configuration deserves the 2-3 style arrangement
and others could do with just a simple _opts macro (ie 4), perhaps not so.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794339518
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)
For a comparison of various alternatives, nothing works better than a
real-world test (using an excerpt from Fedora xterm.spec):
1) Just override the section
```
%conf
%autobuild_conf \
--enable-meta-sends-esc \
--disable-backarrow-key \
--enable-exec-xterm \
%{?with_trace: --enable-trace} \
--enable-warnings \
```
2) Spec tags
```
AutobuildOption(conf): --enable-meta-sends-esc
AutobuildOption(conf): --disable-backarrow-key
AutobuildOption(conf): --enable-exec-xterm
%if %{with trace}
AutobuildOption(conf): --enable-trace
%endif
AutobuildOption(conf): --enable-warnings
```
3) "Add option" style macros (kinda like cmake actually)
```
%autobuild_option conf --enable-meta-sends-esc
%autobuild_option conf --disable-backarrow-key
%autobuild_option conf --enable-exec-xterm
%if %{with trace}
%autobuild_option conf --enable-trace
%endif
%autobuild_option conf --enable-warnings
```
4) One simple _opts macro (with various caveats wrt embedded newlines)
```
%define autobuild_conf_opts \
--enable-meta-sends-esc \
--disable-backarrow-key \
--enable-exec-xterm \
%{?with_trace: --enable-trace} \
--enable-warnings
```
5) A section for declaring options, line by line (similar to eg %patchlist)
```
%autobuild_conf_options
--enable-meta-sends-esc
--disable-backarrow-key
--enable-exec-xterm
%if %{with trace}
--enable-trace
%endif
--enable-warnings
```
2-3, ie the ones most discussed above, are the ones that actually *add* a lot
of technically redundant clutter to the spec. They're are quite readable
though, and although it's not evident here, they have the (non-trivial) benefit
of being relatively freely placeable within the spec: in many/most cases you'd
be able to place the option right alongside eg extra buildrequires for that
option. 3) is even more freely placeable than 2.
5 is the only one that really reduces boilerplate and ugly + brittle
line-continuations, at the cost of forcing the declarations to one spot again,
which is a considerable loss compared to 2-3. It's also way less obviously
independent entries and looks more like a continuous text, which makes you
think there are line continuations missing or something.
4 is only a win over 1 if one assumes complicated autobuild macros that expand
into more than one command so you can't just continue the line as you'd do with
eg %configure.
So it's a curiously contradicting set of possibilities, and despite being more
"wordy", 2-3 have significant advantages over the seemingly more simple
versions.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794302784
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
