Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)
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-management/rpm/discussions/2211#discussioncomment-3769392 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] Properly upstream debuginfo enablement (Issue #2204)
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 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
[Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)
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 regex (I don't know which version this works for). However, this
does not work for other RPM versions.
Is there any documentation for the binary representation of the RPM DB for each
RPM version I could look at?
If there is no documentation for this, where can I find the relevant part of
the source code for the `rpm` binaries? (My thought is if there is no
documentation, I could try reading the source code to figure out how I can
extract the information I need from the RPM DB for each RPM version.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2211
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] Properly upstream debuginfo enablement (Issue #2204)
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 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] Provide a decent API for verifying package signatures (Issue #2041)
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 follow the link above. Have a nice day folks! :wave: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1262264524 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] Properly upstream debuginfo enablement (Issue #2204)
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 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] Properly upstream debuginfo enablement (Issue #2204)
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 or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1262202925
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] Document that `%patch 1` syntax is available and preferred (Issue #2209)
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 (the patch numbers should really be positional arguments, and options are, well, options) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2209#issuecomment-1262111577 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] Document that `%patch 1` syntax is available and preferred (Issue #2209)
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 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
[Rpm-maint] [rpm-software-management/rpm] rpm2archive doesn't check command line switches (Issue #2210)
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 was --nocompress although it was --nocompression, caused some headscratching. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2210 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
[Rpm-maint] [rpm-software-management/rpm] Document that `%patch 1` syntax is available and preferred (Issue #2209)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2209 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
[Rpm-maint] [rpm-software-management/rpm] Fix rpm2archive to behave like rpm2cpio (by default) (Issue #2208)
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 behavior of rpm2cpio. This causes head-scratching from users (me included), inefficient piping because you then need to use 'cat foo.rpm|rpm2archive|tar x' instead of 'rpm2archive foo.rpm|tar x', and it means it cannot replace the aging rpm2cpio which can't handle large files. Once the behavior is made close enough, we can just 'rm rpm2cpio.c' and symlink it to rpm2archive instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2208 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] rpm-sequoia integration missing in the cmake build (Issue #2173)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-sequoia integration missing in the cmake build (Issue #2173)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2173#issuecomment-1262024389 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] Add a better way to run and control buildroot policy (brp) scripts (Issue #2207)
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 parallel execution controlled from C (think file classification and dependency generation). But I imagine there will always be a demand scripts that have a more holistic access to the buildroot than per-file too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2207#issuecomment-1261935652 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] Add a better way to run and control buildroot policy (brp) scripts (Issue #2207)
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 are overriding it, it means us changing defaults doesn't affect a thing anywhere in practise. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2207#issuecomment-1261929196 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
[Rpm-maint] [rpm-software-management/rpm] Add a better way to run and control buildroot policy (brp) scripts (Issue #2207)
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/rawhide/f/macros#_240)). This is no ideal for multiple reasons: - There is no uniform way to do this across distributions - Disabling some scripts in a spec can be distribution dependent - There is a central place that needs adjustment - brp scripts that come from other (rpm-config) packages are hard to integrate - There is no upstream default that distributions can decide to follow or deviate from So a better mechanism is wanted. May be something more akin to a `.d` directory to put stuff in that is run by default with a way to disable things per macro. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2207 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] Properly upstream debuginfo enablement (Issue #2204)
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. But the Dynamic Spec feature has patches to make that work. In addition the `%__spec_install_post` part relies on the decision made by the `%install` part. So removing the later will require a new solution for the former. May be looking at the macros and arch is enough and other decisions can be based on whether debuginfo files were created. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1261886127 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] Properly upstream debuginfo enablement (Issue #2204)
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 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
