Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
> At this point, the drpm library is the only blocker for zstd payloads, > since createrepo_c needs to be able to handle zstd drpms. I looked into the drpm library and I should be able to add the zstd support (and make sure it works with createrepo_c) Working on it now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
> On Fri, Mar 24, 2023 at 05:25:17PM +, Mattia Verga via devel wrote: > I have a few additional questions: > > * How does this impact zchunk? or does it? I also think there shouldn't be any impact on zchunk. > * Kind of unrealted to this change, but I'll ask here as createrepo_c > folks might know off hand: Is it possible to decouple drpms from a repo? > ie, if we had a updates repo and a completely seperate updates-drpms > repo with just drpms in it, what would it take to use that? Changes in > dnf I guess? but also changes in createrepo_c to generate repodata for a > repo that was only drpms? Such repos can be created by createrepo_c and modifyrepo_c but it is a bit awkward. Basically first create normal (coupled) repo and then extract the prestodelta.xml and drpms into a new repo. Additionally createrepo_c API could be used to make it more straight forward. However you are right dnf can't handle that. It looks for deltas in the same repo where it finds the normal update package. It would require changes in dnf and libdnf. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
> If we're planning to drop by-default compatibility with EL7 anyway and bump > to 1.0, we > could go a little bit further. > > * "createrepo_c" doesn't need to support sqlite metadata generation at all, > so long as the repository producer can run "sqliterepo_c". If I recall > correctly, yum on EL7 doesn't actually need the sqlite metadata to be > generated in any > case, it can produce that metadata itself so long as it has the XML. Making > it available > only avoids a local processing step. But if "modifyrepo_c" will be necessary > to > work with most EL7 repos, then making "sqliterepo_c" necessary for a minor > optimization isn't a big leap. We were also discussing adding some "mode" options that could be set to EL7 to generate compatible metadata for EL7 with just createrepo_c. > * createrepo_c currently has two different switches for compression types, > "compress-type" and "general-compress-type", where the latter applies > to everything and the former only applies to files that are *not* "primary", > "filelists", and "other". there should be one compression type option > and it should be applied uniformly to all metadata produced by the > "createrepo_c" tool. Yum would have choked on this because of the special > handling around "comps", but I believe it should no longer be a concern? Yes that is a good suggestion. There are also other command line options that could use some (re)work. For example the unique --xz option which bypasses the mentioned compression options. Unfortunately I am not sure if we will be able to prioritize all the improvements. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
