For now build root policy scripts are just shipped in the
[scripts/](https://github.com/rpm-software-management/rpm/tree/master/scripts)
and it is left to the distributions to run them in ` %__os_install_post`
([Fedora as an
Oh, we do ship a reasonably working default:
https://github.com/rpm-software-management/rpm/blob/master/platform.in#L95
The problem is, any additions (or removals) require one to override the whole
thing, so once you do so you're completely detached from the defaults. And as I
think all
Closed #2173 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2173#event-7484997280
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is kinda hilarious: I'd completely forgotten I had already added Sequoia
integration in the cmake introduction commit
(8c3fb5eb01cae84aca9dac4729e1dce1def59b8c). I just adjusted that to use the now
included pkg-config file and we're good :sweat_smile:
--
Reply to this email directly or
The other shortcoming of brp scripts is that they're expected to run in
parallel and they're getting ever increasingly complicated and brittle because
of it. So going forward the whole mechanism needs a rethink - for many things
you'd actually want a per file-type execution of something, with
FWIW, what I specifically meant by this ticket is the %install override. *That*
has to go. The other bits are far less offensive.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1261867079
You are receiving this
Yeah, but that is the hard part - especially if we want to keep the debuginfo
packages as a macro template. Ofc we could just create those packages in C. But
parsing the template macros after build would be closer to the current
implementation. With the current parser this is a hard ting to do.
I am trying to find an RPM version agnostic way to find details on installed
software on any Linux distro that uses RPM packages.
A co-worker found for one version of RPM that the magic byte array/slice
`[]byte{0, 1, 0x43, 0}` works for extracting each installed package from the
RPM DB using
rpm2cpio outputs to stdout, which makes it natural and efficient to use for
piping: 'rpm2cpio foo.rpm|cpio -idv'. rpm2archive however behaves very
differently by silently creating a .tgz in the current directory. This breaks
the rule of least surprise really, especially given the long-standing
It would be nice to have the `%patch 1` syntax documented, if this is our
future.
BTW I'd be also interested when this was actually introduced, so I know what is
the backward compatibility.
P.S. I don't want to hijack #2205 more then I did, so creating separate ticket
--
Reply to this email
Thanks for filing, seems I had already forgotten how utterly crazy the compat
story was. See commit 02b8d8dccc0f045b0ebf81785cf6ad1056cf550e.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2209#issuecomment-1262103211
You are
Well, guess the easiest way to do this is to get #1485 merged and use that. All
it takes it looking at the results of the `find_debuginfo` run and write
`%{_debuginfo_template}` and `%{_debugsource_template}` into a file. That's
kinda what it was designed for...
--
Reply to this email
So to be clear, `%patch 1` only works as expected in rpm >= 4.18. Prior to
that, it would attempt to apply patches 0 and 1. Go figure :roll_eyes:
The most compatible form by far is `%patch -P1` which AIUI works in every rpm
version out there, only it's not the preferred form for other reasons
This took a ltle bit longer than I expected but I've submitted a patch to
Sequoia to include OpenSSL backend:
https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361
It passes all tests (and adds some more) and I'm planning to run the test suite
from rpm against it but for details
rpm2archive doesn't seem to have any checking for legitimate command line
switches:
This simply hangs (waiting for stdin)
> rpm2archive --nosuch:
This merrily completes:
> cat /tmp/telnet-0.17-86.fc36.x86_64.rpm |rpm2archive --nosuch > /tmp/foo
Discovered when I thought the newly added option
That's one possibility. But we don't *need* to inject macro templates into the
parsed spec to create packages.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1262250066
You are receiving this because you are
Yes, but creating them from C seems like a step in the wrong direction
especially when hard coding the details like Summary and Description.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1262397566
You are receiving
17 matches
Mail list logo
