Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
It's not a bad idea. Gzip is getting a bit long in the tooth, and I guess all distros moved to something better 10-15 years ago. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-9017177 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)
How about defaulting to Zstd compression as opposed to Gzip? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-9014566 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)
I guess it's time to move on with the low-level spec: https://github.com/rpm-software-management/rpm/pull/2988 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8864326 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)
I'd probably go with `RPMTAG_FILEMIME`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8757616 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)
One almost forgotten metadata-level thing added: replace libmagic strings (in RPMTAG_FILECLASS) with MIME classification. I don't know if it makes more sense to reuse the existing tag or reserve a new one just for the purpose though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8756875 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)
So I guess what we could do here is what old tags do when they go to die: rename to OLD-prefix, reuse the name with a new id and add a header extension to retrieve the old tag if new is not set. And, since v4 merrily ignores the old tag being missing, compatibility is retained. So should be doable, but how useful it is in reality I don't know. A new payload format would have to be tracked by an rpmlib() dependency and not just a random string. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8704193 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)
Those three were specifically singled out as only being relevant for v3. Things like caps and payload compressors relate to actual rpm capabilities depending on how it was built, and will need to stay. But .. considering rpm < 4.6 will not be able to read v6 then that's indeed a better cut-off point than general v4, so FileDigests can go, maybe something else too. Note that this is only about *generating* said dependencies into packages. What capabilities librpm provides is a separate matter, eg ExplicitPackageProvides is never generated although it is provided. Ditto for HeaderLoadSortsTags and ConcurrentAccess, maybe something else. But getting rid of those would be just general cleanup. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8704003 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)
>rpmlib() dependencies on v3 compatibility are dropped: Are these being specifically singled out for deletion, or can we blanket-delete feature dependencies introduced before 4.6? Because that's a much longer, e.g. * ExplicitPackageProvides * FileCaps * FileDigests ... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8561838 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)
Heh, I didn't remember the workaround for 3.x, that's pretty funny. That would've been added by a rather green me, probably in 2007 or so, thinking this checking is a good thing. And then nobody thought to update the name when the new payload format was added years later. It's annoying how much that little slip some ten years ago is hurting just now. It's something to consider. While v6 always uses the new non-cpio payload, the community has shown interest in other types of payload too, and having a clean mechanism for this would of course be nice. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8553156 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)
>this cannot be reflected in PAYLOADFORMAT as that would be a gratituous >compatibility break Ironically dropping the tag entirely would work fine, because of the backwards compatibility backflips already in place to deal with v3 packages. https://github.com/rpm-software-management/rpm/blob/1825dbf8244b129665a69481c4537a57b9e03a8f/lib/depends.c#L71 So... why not? The situation already exists where you need to actually look at the payload to figure out what it is, and use RPM to process it in any case. Alternatively can we at least neuter this check and get that backported, so that `PAYLOADFORMAT` could theoretically be fixed in a couple years. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8551719 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)
Oh, RPMSIGTAG_FILESIGNATURELENGTH needs to be dropped because it's just broken. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8543365 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
