Daniel Alley

Well, technically 1.0 is already out, as of the other week... I'd rather not see `sha512` be the default purely on the basis of being twice as long without any...

>and the RPM+DNF infrastructure can handle it I haven't checked but I don't think it does, support would need to be added. edit: nope, not supported. https://github.com/openSUSE/libsolv/blob/86717630b78f015ed3e0d41aa299cdde532b9c6f/src/chksum.c#L122-L139 I just think...

@DemiMarie, what do you think about the above discussion? Would it be worthwhile to start thinking about adopting SHA-3 and/or BLAKE(3|2b|2s) as an alternate checksum type for metadata (createrepo_c &...

IMO, this doesn't feel particularly worthwhile at this point

They mean that when using the `cr_PkgIterator` API, you should be able to leave the filelists xml or other xml arguments as null.

@Conan-Kudo I know you had strong feelings on this a few years ago, what are your thoughts? I know that lazy filelists downloading makes the subject less relevant for Fedora...

@kontura I know you didn't want to go quite this far but I thought there was going to be some functionality deprecated with warnings?

>I guess --general-compress-type and --compress-type was motivated by a microoptimization when some (group) files are too small to be effectively compressed. I.e. a compressed file is larger than an uncompressed...

>No compression has the advantage that it avoids a risk of breaking a compatibility. "none" is not currently even an option in `createrepo_c`. Neither does legacy `createrepo` seem to have...

Submitted https://github.com/rpm-software-management/createrepo_c/pull/411/ for `--compatibility` defaulting to gzip