Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: How to get `can_sign` info? (Issue #2515)
>so you if you restrict version to rpm 4.18 and newer, you can just do >"can_sign = TRUE". That's exactly what I'm doing. I was just afraid of returning a false positive. But if since rpm >= 4.18 rpm only returns signing capable subkeys it's fine. I should just change my comment in the librepo code: "TODO[jrohel]: Set the current value instead of TRUE" -> "rpm returns only signing capable subkeys" -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2515#issuecomment-1682661070 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] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)
@nwalfield Here is the PR https://github.com/rpm-software-management/librepo/pull/275 . It contains commit that moves the original implementation of OpenPGP using GpgMe into "gpg_gpgme.c" file and creates a new based on librpm API in the "gpg_rpm.c" file. There is a function `check_signature` which internally calls `pgpParsePkts` to parse the ASCII armored OpenPGP signature. I created the code based on the description in the "rpmgpg.h" header file and a bit of librpm reverse engineering. It's not very nice, but somehow it works. The code also implements a keyring. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556255299 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] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)
@nwalfield > Why does librepo need to parse signature files? Librepo is used to download data from rpm repositories (metadata, packages, ...). Repository metadata can be signed with an OpenPGP signature. And librepo can verify them. Sample on an existing repository: ``` [google-chrome] name=google-chrome baseurl=https://dl.google.com/linux/chrome/rpm/stable/x86_64 skip_if_unavailable=True gpgcheck=1 gpgkey=https://dl.google.com/linux/linux_signing_key.pub enabled=1 repo_gpgcheck=1 ``` `gpgkey` is a URL to a file containing multiple blocks of ASCII armored public keys (there can be multiple URLs.) The repository contains a "repomd.xml" file and a "repomd.xml.asc" file. **The "repomd.xml.asc" file is an ASCII armored OpenPGP signature that librepo needs to load in order to verify the "repomd.xml" file.** Librepo uses GpgMe. We now have a high priority to remove the dependency on GpgMe. That's why I created a new implementation in the librepo that uses the librpm API instead of GpgMe. Now it works (with some problems that I described in issues, but it works). If the `pgpParsePkts` function does not support ASCII armored signature parsing, how do I load it in the librepo? New better function? Okay, but we need it quickly. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556250287 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] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)
@mlschroe Sorry, I'm not a great English speaker, but I assume that when the function is described as `Parse armored OpenPGP packets from a file.` and returns `type of armor found`, it will return `PGPARMOR_SIGNATURE` after finding the signature. Especially when that value is part of the returned enum. Or something like "NOT_IMPLEMENTED" is also understandable. But `PGPARMOR_NONE`?. I deduce from the description of the function that this is not the expected result for the signature. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556243863 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] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)
@mlschroe In this case, sequoia is fine. But the internal implementation is incomplete. But in my opinion, there was no pressure to complete the support. We used GpgMe instead of this API. Details: The `pgpReadPkts` function returns the `pgpArmor` enum, which since its creation in 2001, contains an entry for the signature `PGPARMOR_SIGNATURE` (and other entries). And the function is described: "Parse armored OpenPGP packets from a file." And it returns "type of armor found". In fact, it only parses one type `PGPARMOR_PUBKEY`. ``` /** \ingroup rpmpgp * Parse armored OpenPGP packets from a file. * @param fnfile name * @param[out] pkt dearmored OpenPGP packet(s) (malloced) * @param[out] pktlen dearmored OpenPGP packet(s) length in bytes * @return type of armor found */ pgpArmor pgpReadPkts(const char * fn, uint8_t ** pkt, size_t * pktlen); ``` ``` PGPARMOR_MESSAGE= 1, /*!< MESSAGE */ PGPARMOR_PUBKEY = 2, /*!< PUBLIC KEY BLOCK */ PGPARMOR_SIGNATURE = 3, /*!< SIGNATURE */ PGPARMOR_SIGNED_MESSAGE = 4, /*!< SIGNED MESSAGE */ PGPARMOR_FILE = 5, /*!< ARMORED FILE */ PGPARMOR_PRIVKEY= 6, /*!< PRIVATE KEY BLOCK */ PGPARMOR_SECKEY = 7 /*!< SECRET KEY BLOCK */ ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554461685 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] OpenPGP: `pgpDigParamsUserID` function returns only primary user id. How to get others? (Issue #2517)
-- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2517 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] OpenPGP: How to get subkey fingerprint? (Issue #2516)
Now I use `pgpPubkeyFingerprint` function. But it looks like it only allows to get a fingerprint of the main key. How to get fingerprint of subkeys? Similarly, the `pgpPubkeyKeyID` function returns the main key ID. But I discovered a `pgpDigParamsSignID` function that returns a keyID for a subkey. So OK. But how do I get the fingerprint for the subkey? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2516 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] OpenPGP: How to get `can_sign` info? (Issue #2515)
GpgMe provides a lot of information (attributes) about keys/subkeys - `revoked`, `expired`, `can_sign`, So far we have used `can_sign` in the librepo library. How to get this information via librpm API? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2515 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] OpenPGP: Function `pgpParsePkts` missing length argument (Issue #2513)
The `pgpParsePkts` function does not have a `armorlen` argument. Instead, it requires a null-terminated input buffer. It assumes that the input is a C string. It's not a blocker for me. I made a workaround, I copy the buffer from the user to the temporary buffer, where I add the terminating zero character. It's not ideal, it costs extra memory and CPU time. So a tip for an extension/new API. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2513 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] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)
I am preparing a new backend for OpenPGP support in librepo
https://github.com/rpm-software-management/dnf5/issues/438 . Instead of GpgMe,
it uses the librpm library API. The goal is to get rid of the dependency on
GpgMe.
I need support for loading ASCII armored PGP signatures. I found it works with
"rpm-sequoia" backend. The problem is with internal librpm implementation.
Is there a plan to add support for ASCII armored PGP signatures to librpm's
internal implementation? Or will an external implementation ("rpm-sequouia"
backend) be required in future versions (e.g. next Fedora)?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512
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] OpenPGP: Function `pgpParsePkts` parses only first packet (Issue #2487)
@nwalfield 1. Yes. I meant the case when there are multiple ascii-armor blocks in one file (or memory block). I apologize for the terminology confusion. 2. I'm looking into how the code you linked for [rpmkeys --import](https://github.com/rpm-software-management/rpm/blob/b447ad31fb4567c524938edd65112a6476113a2e/lib/rpmchecksig.c#L27) does this. The code shows exactly the same problem I ran into. It solves the problem as I suggested in point 2. That is, the `pgpParsePkts` function is called multiple times in a `do` loop. And the fact that it doesn't return the offset of the end of the processed ascii-armor block is solved (a dirty hack from my point of view) by searching the already parsed block with the `strstr` function (search for string "-BEGIN PGP "). So I'll do the same, but correctly my code shouldn't know that the ascii-armor block starts with the string "-BEGIN PGP ". The `pgpParsePkts` function will find the first occurrence of the beginning and end of the block by itself. It's its job to parse the ascii-armor data. And it's a shame that it doesn't return the offset of the end of the block (even though it knows that), and instead I have to search the block again to find where the next one starts. But OK, it's still better than writing a whole parser. Anyway, thanks for the response. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2487#issuecomment-1512563261 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] Function `pgpParsePkts` parses only first packet (Issue #2487)
Problem: After first packet function returns. Next packet are ignored. Example solutions: 1. Parse all packets. 2. New function that parse one packet but returns one more parameter with offset of the packet ends. To be able to call the function again from that point. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2487 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 transaction set change notification callback (#1367)
@pmatilai I am working on a new microdnf. I did some tests of your new C API. It is really an improvement. I have a better overview of the packages in the transaction now. There is still a grey area for me. Transaction elements with scriptlets. Example: The "iftop" package reinstall action runs scripts from other packages that are installed but not part of the transaction. New API provides transaction element (instead of header) in the calbacks. So I can see more information about scriptlets. I see: `rpmteType` is `TR_RPMDB` /*!< Package from the rpmdb. */, `rpmteParent` is `NULL`, `rpmteDependsOn` is `NULL` The question is, who triggers this scriptlet? Dependency between scriptlets? It was a simple example. However, for a bigger transaction with multiple packages, the question is: Why the scriptlet from installed package XY was started? Perhaps this is seen in the chronological order of callbacks. **Anyway, I have more information than before. And the new C API is better and new callbacks helps. I hope the new API will be merged soon. I especially need the C API as soon as possible. Now I use my own RPM build with your PR backported.** === ### Example output from my new testing microdnf: **microdnf reinstall iftop** ``` ts_change_callback: 1 0x90abd0 (nil) 0x7a9fe8 ts_change_callback: 1 0x7a1440 0x90abd0 0x7a9fe8 Running transaction: [1/2] Verify package files 100% | 333.0 B/s | 1.0 B | 00m00s [2/3] Prepare transaction 100% | 7.0 B/s | 2.0 B | 00m00s [3/4] Reinstalling iftop-0:1.0-1.0.x86_64 100% | 4.2 MiB/s | 108.3 KiB | 00m00s [4/4] Cleanup iftop-0:1.0-1.0.x86_64 100% | 45.0 B/s | 11.0 B | 00m00s >>> Running scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Stop scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Running scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Stop scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 --- [4/4] Total100% | 206.0 KiB/s | 108.3 KiB | 00m00s ``` **microdnf reinstall man-db-0:2.9.0-3.fc32.x86_64** ``` ts_change_callback: 1 0x18fac80 (nil) 0x18f4788 ts_change_callback: 1 0x1938680 0x18fac80 0x18f4788 Running transaction: [1/2] Verify package files 100% | 90.0 B/s | 1.0 B | 00m00s [2/3] Prepare transaction 100% | 7.0 B/s | 2.0 B | 00m00s >>> Running scriptlet: systemd-0:245.6-245.6.x86_64 >>> Stop scriptlet: systemd-0:245.6-245.6.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 [3/4] Reinstalling man-db-0:2.9.0-2.9.0.x86_64 100% | 12.1 MiB/s | 2.5 MiB | 00m00s >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 [4/4] Cleanup man-db-0:2.9.0-2.9.0.x86_64 100% | 473.0 B/s | 326.0 B | 00m00s >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Running scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Stop scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Running scriptlet: systemd-0:245.6-245.6.x86_64 >>> Stop scriptlet: systemd-0:245.6-245.6.x86_64 >>> Running scriptlet: systemd-0:245.6-245.6.x86_64 >>> Stop scriptlet: systemd-0:245.6-245.6.x86_64 >>> Running scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Stop scriptlet: glibc-common-0:2.31-2.31.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Running scriptlet: man-db-0:2.9.0-2.9.0.x86_64 >>> Stop scriptlet: man-db-0:2.9.0-2.9.0.x86_64 --- [4/4] Total100% | 2.2 MiB/s | 2.5 MiB | 00m01s ``` -- 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/1367#issuecomment-698744467___ 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 transaction set change notification callback (#1367)
@pmatilai It seems useable now. I will try to use new C API (PRs #1365, #1366, #1367) and do a simple tests. -- 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/1367#issuecomment-696637236___ 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 support for application private user data in transaction elements (#1366)
@jrohel commented on this pull request.
> as passed e.g. as data arg ts.addInstall()"},
+{"Priv", (PyCFunction)rpmte_Priv,METH_NOARGS,
+ "te.Priv() -- Return associated user data (if any)\n"},
+{"SetPriv",(PyCFunction)rpmte_SetPriv, METH_O,
+ "te.Priv() -- Set associated user data (if any)\n"},
`"te.SetPriv(userdata) -- Set associated user data (if any)\n"`
Note:
I prefer `userdata` instead of `priv`.
Example: `SetUserData ()`, `GetUserData ()`/`UserData ()`. Below the `priv`, I
can imagine a something other.
And in the callback `void *userdata` instead of` void *priv`.
But that's my feeling.
--
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/1366#pullrequestreview-493318411___
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 alternative transaction callback style (#1365)
@pmatilai Python API: >From my point of view the new mode arguments (rpmte, what, amount, total, >userdata) are much better than the old ones. And it is almost the same as in >the new C API mode. I prefer to drop "key" argument from this new API. -- 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/1365#issuecomment-696551652___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New transaction callback mode based around transaction elements (#1363)
@pmatilai Thanks for PR. Passing user data was missing for long time. I have a note on setting up user data. We have a new API function `void rpmteSetPriv(rpmte te, void * priv)`. But when an user creates a new transaction element (using `rpmtsAddInstallElement`/`rpmtsAddReinstallElement`/`rpmtsAddEraseElement`) he don't get a pointer to it. Pointer to it (rpmte value) is needed to use the new API function `rpmteSetPriv`. In the `tests/rpmpython.at` all transaction elements are created. Then transaction set is iterated. Transaction elements are modified (user private data added). It is not user friendly API. Ideally we want set it during transaction element creating time. >From your example I assume: - transaction elements are in the transaction set in the order in which the user created them - no transaction elements are automatically added/removed And user can do something like this: ``` ret = rpmtsAddReinstallElement(ts, h, key); int lastAddedTElementIdx = rpmtsNElements(ts) - 1; rpmte lastAddedTElement = rpmtsElement(ts, lastAddedTElementIdx); rpmteSetPriv(lastAddedTElement, user_data); ``` Am I right? -- 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/1363#issuecomment-695916627___ 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 rpmtsAddEraseElement2 to API, extend rpmtsAddEraseElement with key data (#1360)
@pmatilai I have no problem with NAK if there will be a better solution. And I looked at your PR # 1363. Thanks, it seems like a good start. I'll look at it closely. -- 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/1360#issuecomment-695040868___ 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 API for clone rpmps iterator (func rpmpsiClone) (#1359)
I wanted to create standard forward (or input) C++ iterator which satisfies copy-constructible, copy-assignable and can be incremented (pre-increment, post-increment). -- 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/1359#issuecomment-694802602___ 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 rpmtsAddEraseElement2 to API, extend rpmtsAddEraseElement with key data (#1360)
> The key is not arbitrary "user data", the purpose of the key argument is to > allow install callback to locate and open the associated package file and is > used and passed around for this very purpose in rpm. There's no counterpart > for opening an erasure element because this doesn't seem meaningful. >From my point of view as a user of the rpm library, the "key" is a pointer to >generic user data (arbitrary, a pointer to a void), which I pass to the >library and it returns to me in callbacks. I need it to pair the callback with >the original transaction element. Specifying an associated package to install >is just one reason. I also need to pair during erase surgery. I know purpose >for using this argument in rpm. But do all programs have to use this pointer >to void by the same way? I think, for rpm library it's just a pointer. > Any implicitly added erasures (for upgrades and obsoletes) would still not > have a key Yes. I know. But we have prepared transaction with all elements explicitly added. And we need pair callbacks with these elements. > I can see a need for carrying "user data" in rpmte, but the key has a very > specific meaning in rpm and overloading this to other purposes is not likely > to end well. > Thinking about this, I think a more constructive approach would be adding a > separate, truly private userdata member to transaction elements and an > optional transaction set callback which gets called whenever something > changes in the transaction set, which can be used for setting userdata on > both explicitly and implicitly added elements (and whatever other purposes, > such as easily locate the newly added rpmte element) and doesn't require ugly > foo2() functions (or API breakage). I'm glad you see the need to transfer "user data". If you add a new better API I will be happy. But until then, at least this small improvement to the old API will help us. I don't want to break the existing API. So, I was just looking for a way to get a user pointer into erase element in the existing API with minimal code changes and without breaking it. And I introduce new API function. The name of the new function is ugly ... that is why I wrote note: "better API function name name than rpmtsAddEraseElement2 ?" Can you suggest a better one? -- 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/1360#issuecomment-694793202___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add rpmtsAddEraseElement2 to API, extend rpmtsAddEraseElement with key data (#1360)
Transaction set API offers functions to add items (packages) to transaction set: ``` int rpmtsAddInstallElement(rpmts ts, Header h, const fnpyKey key, int upgrade, rpmRelocation * relocs); int rpmtsAddReinstallElement(rpmts ts, Header h, const fnpyKey key); int rpmtsAddEraseElement(rpmts ts, Header h, int dboffset); ``` User can attach user data (key argument) to the transaction item. However, user data cannot be attached in the case of `rpmtsAddEraseElement` function. This fix add a new API function `rpmtsAddEraseElement2` (to not break the existing one) with added parameter `key` parameter. `int rpmtsAddEraseElement2(rpmts ts, Header h, int dboffset, const fnpyKey key);` Notes: - PR helps to solve issue: https://github.com/rpm-software-management/rpm/issues/1213 - better API function name name than `rpmtsAddEraseElement2` ? - `dboffset` is still not used You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1360 -- Commit Summary -- * Add rpmtsAddEraseElement2 to API, extend rpmtsAddEraseElement with key data -- File Changes -- M lib/depends.c (15) M lib/rpmts.h (10) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1360.patch https://github.com/rpm-software-management/rpm/pull/1360.diff -- 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/1360 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add API for clone rpmps iterator (func rpmpsiClone) (#1359)
There are missing API for cloning iterators in rpm library. PR adds function for cloning rpm problem set iterator. The same is needed for others iterators. Eg. for creating post-increment `operator++(int)` in C++ wrapper. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1359 -- Commit Summary -- * Add API for clone rpmps iterator (func rpmpsiClone) -- File Changes -- M lib/rpmps.c (11) M lib/rpmps.h (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1359.patch https://github.com/rpm-software-management/rpm/pull/1359.diff -- 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/1359 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
