Re: [Rpm-maint] [rpm-software-management/rpm] Add --list-keys and --delete-key to rpmkeys (PR #2921)
I think I initially wanted to add a sane API for these and then have rpmkeys use that, and when that seemed painful I gave up. But the user wont care *how* it's achieved if it works in a meaningful manner. And, for the user this is far saner than 'rpmkeys --import -> rpm -q -> rpm --erase'. Two things: 1) Lets make the option names consistent - either they all should have plural -keys, or none should have it. Since the pre-existing --import doesn't have it, maybe the --delete and --list shouldn't have either? Or, we could add --import-keys as alias to --import. 2) Tests for both added operations. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#issuecomment-1956077388 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 --list-keys and --delete-key to rpmkeys (PR #2921)
@pmatilai commented on this pull request. > @@ -75,7 +74,29 @@ int main(int argc, char *argv[]) break; /* XXX TODO: actually implement these... */ Maybe delete this comment while at it? :smile: A fine example of why comments are so bad - they don't get updated along with the code. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892306320 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 --list-keys and --delete-key to rpmkeys (PR #2921)
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
case MODE_DELKEY:
+ struct rpmInstallArguments_s * ia =
+ ARGV_t gpgargs = argvNew();
+ for (char * const * arg = args; *arg; arg++) {
+ if (strncmp(*arg, "gpg-pubkey-", 11)) {
+ char * gpgarg = rpmExpand("gpg-pubkey-", *arg, NULL);
Why the macro expand? That seems weird/wrong in this context.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892305237
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] Reproducible builds improvements (Issue #2894)
Forward-looking defaults aside... Do you agree with the idea that there should be a single macro to set the buildtime source (clock/macro/source_date_epoch), and then have a separate flag for clamping mtimes to buildtime, or am I again missing some finer detail here? I've nothing against reproducible builds, it's this tangle of haphazard switches that annoys me. Tagging in folks who I remember showing interest in reproducible builds in the past, feel free to include more if/when I missed someone: @JanZerebecki @Conan-Kudo @bmwiedemann @boklm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956052423 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 --list-keys and --delete-key to rpmkeys (PR #2921)
This feels a bit too quick and dirty. Comments welcome. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#issuecomment-1956047845 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 --list-keys and --delete-key to rpmkeys (PR #2921)
This is a bit of a hack as it manipulates the parsed cli parameters to to the right thing and then calls rpmcliQuery and rpmErase. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2921 -- Commit Summary -- * Add --list-keys and --delete-key to rpmkeys * Dont advertise rpm -qa gpg-pubkey* in man page -- File Changes -- M docs/man/rpmkeys.8.md (18) M tools/rpmkeys.c (25) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2921.patch https://github.com/rpm-software-management/rpm/pull/2921.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921 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] `update-po` target fails (needs submodule update) (Issue #2899)
(and fwiw, pulling that path change into 4.19.x makes no difference whatsoever because the translations should NOT be updated in the branches, and hence there's no reason to do so) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956030258 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] `update-po` target fails (needs submodule update) (Issue #2899)
So with the submodule update done, this can be closed. Sorry @dmnks for stealing your ticket :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956028313 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] `update-po` target fails (needs submodule update) (Issue #2899)
Closed #2899 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#event-11871913923 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] `update-po` target fails (needs submodule update) (Issue #2899)
Well yeah, *ideally* you'd have an official string freeze period with translation notifications for major releases. And ideally you'd also have per-release branches for translations because over time they grow different so you can't safely pull updated translations to stable releases. Why we never did that? Because it's just too much hassle for the benefit, for a tool like rpm. This ticket is a bit funny because we don't *have* any "update-po" target at all. There's just "update-pot". The ticket summary talks about -po, the initial post about -pot and then later again -po, so it's kinda hard to tell what is actually meant by that. In any case, "update-pot" *should* be functional in git master, and be run during alpha/beta/final releases of a new major release. I updated the po submodule just now to pull in the path changes at least, but the current POTFILES.in approach is not sustainable, that needs to change to something like "any *.c files". However "update-pot" (and consequent push) should NOT be run from stable releases because there's no corresponding branch in the translations. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956026332 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
And here they are. I update the lockfile format with items `checksum` and (file) `size`. There is also an expansion in the header (two new records: `lockfileVendor` and `lockfileType` - that distinguishes between _rpms.in.yaml_ and _rpms.lock.yaml_). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8536404 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] `update-po` target fails (needs submodule update) (Issue #2899)
> Oh, and just to clarify, in the case of 4.19.1.1, we did _not_ intend to > update the translations in that release at all, which is why this issue > wasn't caught yet. Just FTR: updating translations should be be part of the (pre)release process. Email addresses taken from each .po files should be used to spread notifications "I'm going to release new version of software X in next N days. Please update translations". This shuld be predeceased by `make -C po update-po` and commit to the all .po files. As long as translations are kept in separated repo it makes that harder to sync and to keep track of all changes between version (because tag repo A do not causes that such tag is propagated across submodule). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-195454 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 v6 package format, first public draft for commenting (Discussion #2374)
Because in rpm < 4.18, we have this silly check in there:
```
if (lead->major < 3 || lead->major > 4) {
*msg = xstrdup(_("unsupported RPM package version"));
return RPMRC_FAIL;
}
```
Putting 6 in the otherwise unused lead would render v6 packages unreadable by a
huge range of older rpm versions that have otherwise zero problems accessing
it. It's just not worth it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8530795
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 v6 package format, first public draft for commenting (Discussion #2374)
Why can't 6 go there? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8530347 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] 4.19.1.1: `update-po` target fails (Issue #2899)
Oh, and just to clarify, in the case of 4.19.1.1, we did *not* intend to update the translations in that release at all, which is why this issue wasn't caught yet. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1954201323 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] 4.19.1.1: `update-po` target fails (Issue #2899)
This is already fixed in the rpm-l10n repo, in the commit https://github.com/rpm-software-management/rpm-l10n/commit/b4dc72f4b92489f77de9b0ae0bed754875d37ece, we just need to update the `po` submodule in the main repo to pull that change. > IMO It would be hoof to add excutinh that target at least in dist tar ball > process formation and/or in CI. This is currently a manual step in our [release process](https://rpm.org/devel_doc/release_maintaince.html) as pulling any kind of additional content, even if just translations, should always be reviewed and double-checked before making a release. That said, we could probably integrate it into a cmake target indeed, thanks for the suggestion! We're gradually moving towards a more automated release process so this would be another piece of the puzzle. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1954197518 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 v6 package format draft, major update (Discussion #2919)
Figuring out what to do with this is one of the next things on my plate. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529580 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 v6 package format draft, major update (Discussion #2919)
There's now also a draft PR that implements mosts of this draft, as far as package generation goes: https://github.com/rpm-software-management/rpm/pull/2920 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529509 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 v6 package format draft, major update (Discussion #2919)
> proper multiarch dependencies (instead of ()(64bit) markers) As a reminder, I took a stab at this in #360 and later #1038. The big change since then is the introduction of subarches for both ARM and x86_64, and I still expect that to happen for RISC-V too. What are we thinking for this now? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529506 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 v6 package generation rough-cut (PR #2920)
@pmatilai pushed 2 commits. 30d352e1c188a68fdeb97fd1737d3eba891a19ee Don't populate os and arch in the lead structure 01df85ccec5c00ebd46802a67fcc53f8274926a3 Bump the rpm version in the lead to 4 for v6 packages -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2920/files/c554dd15cea584e69949e3ee62a2df931e27ab94..01df85ccec5c00ebd46802a67fcc53f8274926a3 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] CMakeLists.txt: eliminate floating dependencies (PR #2914)
We didn't even do this with the Autotools build scripts, I don't think we should make it so strict in the CMake build script either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1954138148 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] RPM v6 package generation rough-cut (PR #2920)
This should fairly closely reflect the latest v6 draft just published at https://github.com/rpm-software-management/rpm/discussions/2919 The focus here is on the generation of v6 format packages, asserting various aspects of the format is mostly a post 4.20 topic. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2920 -- Commit Summary -- * Add tests for v6 package structure and digests, equal to v4 just now * First commit of rpm v6: add version switch, drop obsolete signature tags * Introduce new payloadsize + alt tags in the v6 main header * Always use long filesizes and the new non-cpio payload format on v6 * Add a new unique v6-only reserved signature tag below header base * Add rpm package format version as a tag to = v6 packages. -- File Changes -- M build/files.c (7) M build/pack.c (49) M build/rpmbuild_internal.h (1) M build/spec.c (1) M include/rpm/rpmtag.h (6) M lib/signature.c (15) M lib/signature.h (4) M macros.in (6) M sign/rpmgensig.c (7) A tests/data/misc/rpmdump6.txt (394) M tests/pinned/common/buildrepr.sh (1) M tests/pinned/common/rpmsigdig.sh (2) M tests/pinned/rpmsigdig.txt (2) A tests/pinned/rpmsigdig6.sh (5) A tests/pinned/rpmsigdig6.txt (11) M tests/rpmgeneral.at (3) M tests/rpmpkgfmt.at (17) M tests/rpmsigdig.at (3) M tools/rpmdump.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2920.patch https://github.com/rpm-software-management/rpm/pull/2920.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2920 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
There's now what should be much closer to final (but isn't yet, certainly) draft with clarified scope and compatibility info at https://github.com/rpm-software-management/rpm/discussions/2919 Closing this topic as it has served its purpose and is getting too cluttered to follow. Thanks everybody for the feedback so far! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8528994 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 v6 package format, first public draft for commenting (Discussion #2374)
Closed #2374 as resolved. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374 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] RPM v6 package format draft, major update (Discussion #2919)
Based on the feedback on the [initial draft](https://github.com/rpm-software-management/rpm/discussions/2374) and work in the background, here's a major update to the v6 package format draft. Starting a new topic as the original one is getting bogged down in details that are no longer relevant. There are still some open questions and details but by now the scope is much clearer, and this should give the reader a fair idea of what to expect in the final spec. # RPM v6 package format (draft v0.8) ## Summary RPM v6 is a face-lift on the existing RPM package v4 format, not a radical redesign. The primary motivations for v6 are to bring RPM to this millenium technology-wise: eliminate long obsolete crypto, ensure sufficiently large sizes everywhere and shed compatibility babbage from the last 20 years. ## Format The following mainly describes differences to the [v4 format](https://rpm-software-management.github.io/rpm/manual/format_v4.html). The fundamental file-format in v6 remains the same: an rpm package consists of - lead - signature header - main header - payload, optionally compressed "Dropped" in the following sections means: no longer generated or accepted in the v6 format itself. As part of v4 packages, they will remain accepted as long as v4 is relevant (ie, a long long time). ### Compatibility As the v6 format is largely built from extensions to the v4 format, it is largely compatible with later rpm 4.x versions. Roughly, v6 format packages can be - read and queried by rpm >= 4.6 - unpacked by rpm >= 4.12 - verified by rpm >= 4.14.2 - installability varies based on used feature set, tracked via rpmlib() dependencies ### Headers - tag entries are always sorted - tag numbers are unique across signature and main header - duplicate tags are not permitted - all padding must be zeros - 64 bit sizes everywhere - package-level sizes - file sizes - crypto modernization: - MD5 and SHA1 dropped everywhere - DSA1 dropped everywhere ### Lead - major version is 4 (rpm 4.x used 3) - os and arch are zeros ### Signature header - header+payload digests and signatures (aka V3 signatures) are dropped (v3 signatures are no longer generated by default since 4.16) - RPMSIGTAG_MD5 - RPMSIGTAG_PGP - RPMSIGTAG_GPG - RPMSIGTAG_PGP5 - all size tags are dropped: - RPMSIGTAG_SIZE - RPMSIGTAG_LONGSIZE - RPMSIGTAG_PAYLOADSIZE - RPMSIGTAG_LONGARCHIVESIZE - signature reservation moved to a new tag number 999 (RPMSIGTAG_RESERVED) - eliminate tag value conflicts between signature and header tags - happens when all of the above is done: all signature tags are between 256 and 999 - drop RPMTAG_SHA1HEADER - open questions: - protect ima + fsverity signatures somehow (separate signature?) - use RPMSIGTAG_RESERVED also for signature self-padding? ### Main header - file sizes are always 64bit: - RPMTAG_LONGFILESIZES - RPMTAG_LONGSIZE - RPMTAG_LONGARCHIVESIZE - 32bit size tags are dropped: - RPMTAG_SIZE - RPMTAG_FILESIZES - RPMTAG_ARCHIVESIZE - new payload size tags (always 64bit): - RPMTAG_PAYLOADSIZE - RPMTAG_PAYLOADSIZEALT - new tag to carry package format version (RPMTAG_FORMAT or such) - always utf-8 encoded - group tag is made optional ### Payload - always in the "new" large file format, never cpio - this *cannot* be reflected in PAYLOADFORMAT as that would be a gratituous compatibility break ## Metadata level - rpmlib() dependencies on v3 compatibility are dropped: - PayloadFilesHavePrefix - CompressedFileNames - PartialHardlinkSets - proper multiarch dependencies (instead of ()(64bit) markers) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919 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] Please backport support for spec local file attributes and generators into stable RPM (Issue #2918)
I wonder if you would be open to backport the support for [spec local file attributes and generators](https://github.com/rpm-software-management/rpm/pull/2911) into stable RPM. This would allow us to drop the rpm-local-generator-support package from Fedora and migrate the current downstream users to the `_local_file_attrs` instead. I have already asked [backport in Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=2264885), but I was redirected here. And to be fully transparent, I am asking the backport here and now, because it would actually allow us to drop the rpm-local-generator-support package from Fedora and hopefully also from RHEL10. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2918 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Fedora also used Mirror Manager, therefore the explicit URLs (in the original example) are going against that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8528588 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 v6 package format, first public draft for commenting (Discussion #2374)
Coming back to this: to avoid gratuitious compatibility breakage, we can't put either 0 or 6 in there. The best we can do is put 4 in there because all of rpm 4.x used 3 as the major version for alleged LSB compatibility, so it at least differentiates it a bit. It's not such a terrible lie even because the fundamental header structure of v6 is basically v4... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8528530 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] No build directives in generated spec parts (PR #2917)
@pmatilai commented on this pull request.
> @@ -21,6 +21,11 @@
#define ALLOWED_CHARS_EVR ALLOWED_CHARS_VERREL "-:"
#define LEN_AND_STR(_tag) (sizeof(_tag)-1), (_tag)
+enum parseStages {
+SPECFILE,
+BUILDSYS,
+GENERATED,
Use some unique prefix on the enum names, makes it easier to grep for affected
places, something like STAGE_FOO or PARSE_FOO.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1890141434
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] No build directives in generated spec parts (PR #2917)
@pmatilai commented on this pull request.
> + if (stage == GENERATED) {
+ switch (tag) {
+ case RPMTAG_SOURCE:
+ case RPMTAG_PATCH:
+ case RPMTAG_NOSOURCE:
+ case RPMTAG_NOPATCH:
+ case RPMTAG_EXCLUDEARCH:
+ case RPMTAG_EXCLUSIVEARCH:
+ case RPMTAG_EXCLUDEOS:
+ case RPMTAG_EXCLUSIVEOS:
+ case RPMTAG_BUILDROOT:
+ case RPMTAG_BUILDCONFLICTS:
+ case RPMTAG_BUILDOPTION:
+ case RPMTAG_BUILDPREREQ:
+ case RPMTAG_BUILDREQUIRES:
+ case RPMTAG_BUILDSYSTEM:
Add this info to the struct in preambleList instead, that forces one to
consider this issue whenever new tags are added.
You can check for this from findPreambleTag() just as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1890134783
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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Just a random observation: Fedora is being used as the example here, but Fedora does NOT preserve the updates history in the repository, only the first (in the base repo) and the last are kept. So any of this basically requires maintaining a local mirror which never deletes packages. And with that, you can't use official repodata either, you need to create your own or use explicit URLs (as the examples here do). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8528247 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Right, RPM does not have any concept of repos. As it mostly does not care about URLs and generally does not care about where the RPM comes from. But let me explain what I mean. This lock file (based on your initial example, and sorry if I don't have the YAML syntax right) in the simplest form could be interesting for RPM IMHO: ~~~yaml lockfileVersion: 1 packages: - vim-enhanced-9.1.031-1.fc38.x86_64.rpm - vim-common-9.1.031-1.fc38.x86_64.rpm - vim-filesystem-9.1.031-1.fc38.noarch.rpm - gpm-libs-1.20.7-42.fc38.x86_64.rpm - ... ~~~ If I did `rpm -I vim-enhanced-10.0.038-1.fc38.x86_64.rpm`, the command would fail, because the NVR does not match the lock file. If I did `rpm -I foo`, this wold also fail, because `foo` package is not listed in the lock file. But doing `rpm -I vim-enhanced-9.1.031-1.fc38.x86_64.rpm` would work. On top of that, if the command would be `rpm -I https://mirrors.nic.cz/pub/fedora/linux/updates/38/Everything/x86_64/Packages/v/vim-enhanced-9.1.031-1.fc38.x86_64.rpm` RPM could also check the URL if it was part of the lock file as in your initial proposal. IOW this would allow version pinning which could probably be useful RPM feature. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527930 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
NVR does not uniquely identify a package. URL neither, but it's good enough if you trust the server the URL points to. Full identification only guarantees a checksum (and event that has theoretical collisions). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527708 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
Just to keep this in sync what was discussed via a private channel, package checksums (in some form) will need to be introduced to the format. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527603 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
> maybe ignoring the full URL just focusing on NVR @voxik There are use cases where you cannot rely on packages residing in a repo, e.g. a single 3rd party package hosted on a page somewhere in which case you need a URL to get it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527454 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
> Building a container for multiple architectures is single use-case, actually > a use-case that will be more and more common because x86_64 arch domination > is shifting (wide adoption of ARM, rise of RISC) so multi arch builds are > must have and consistency between arches is desired. I don't think this is > (and ever was a private use-case). I never argued against multiple architectures... > If you want to have separate arches, it can be still easily done, current > format doesn't block this in any way. Frankly it also feel more natural to > have architecture listed in the file directly rather then encoding it into > the filename, where it may get lost if you share just the file content (e.g. > sharing by sharing file content via paste-bin or GitHub Gists). ...nor did I suggest encoding the arch into the file name. I only commented on the fact that we're treating the lockfile not as an input for a single operation, but from what I can see - a batch operation, IOW use a single lockfile for a single artifact prefetch which will then be re-distributed among multiple concurrent arch builds of the same container. My only argument revolves around let's call it "pipeline encapsulation", meaning that there should be a single architecture prefetch for a single container build (again, we're getting too specific in the overall use case of the lockfile as proposed, but okay). So, yes, the current format doesn't block single arch use cases, however, I wonder if more than a single arch (doesn't matter which one, the lockfile would tell you that with an attribute)in the lockfile is a desirable design. Let me elaborate on this some more so that it's clear why I'm even poking it. As you propose, sources would be tied to architecture, however, that's not always the case (e.g. Fedora) so from that perspective sources should be modeled outside of a given architecture, but that's a Fedora policy, not a DNF constraint, so some sources will be architecture-dependent and some won't which naturally leads to a split design of how source RPMs should be modeled in the YAML depending on what distro and arch you use. Conversely, if you only ever allow the lockfile to describe a single architecture instead of batching, it doesn't matter because you'll only ever process a single architecture, so you'd always model sources the exact same way whether they're tied to an architecture or not, it would be modeled as just another repo like all the others, it would just happen to be for srpms. Maybe I'm being naive but it would IMO simplify the design some more without sacrificing too much on the pipeline use case, you'd just need to have multiple lockfiles stored (one per arch) which to me sounds like a reasonable tradeoff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527430 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] Introduction of "rpms.lock.yaml" file (Discussion #2908)
RPM checks dependencies, doesn't it? Then I don't see why RPM should not allow only the dependencies as specified in some lock file, maybe ignoring the full URL just focusing on NVR -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8526953 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
