That's the wrong end to be looking at, totally.
'rpm -q' with
[--queryformat](https://rpm-software-management.github.io/rpm/manual/queryformat.html)
gives you access to every single bit of data in the rpmdb.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
And I didn't say those should or need to be hardcoded in C. Just that it
doesn't need the kind of templates we have now, those are pretty rigid too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1263165798
You are re
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 re
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
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 just
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 subscribe
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 directly
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 (
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 receiving
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 w
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 d
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 b
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 ma
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 v
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 pa
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 distros
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
example](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/raw
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.
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 becaus
19 matches
Mail list logo