RPM Support

Everything should be easy and without any issues when every package in a repo is downloaded. This is the case for:

• immediate download policy, after sync is performed
• uploaded packages
• already downloaded packages copied from other repos

Other cases:
1. On_demand repo, no packages from other sources, first sync from the remote source.

• If the requested checksum type is different from what is available, publish with available checksum type + log a warning that the requested checksum type can't be used

2. Mixture of packages from different on_demand repos

• If on_demand repos have different checksum types, there is no way out -> fail

3. Mixture of downloaded content and in_demand.

• If on_demand content has the common checksum type, it should be used, otherwise fail.

4. On_demand repo, Nth sync, a checksum type in a remote repo changed

• Not sure what to do with it. We can publish using old checksum type but I guess expectation would be that the new checksum type is used.

Concerns:
- we don't have info about remote repo checksum type, we have checksum type info for each package in a RemoteArtifact.
- does it mean that we should inspect all RemoreArtifacts to figure out what the common checksum type is for on_demand content?

Case 1.
I wonder if we could just fail the publish with the helpful explanation message? This way we could be sure this kind of incompatibility is acknowledged by user and he'd update the checksum type or resync the repo with immediate policy.

Case 4.
I don't think we can somehow possibly be aware of the changes happened remotely unless we resync. We publish what we have synced down locally.

My two cents:

• checksum types on metadata are not a security feature
• Publishing a repository should work all the time, even if a consistent checksum type is not used
• Publishing should never fail (unless the user explicitly declares they want it to fail unless some condition is met)

In my experience, Katello's end users are met with pure confusion when any of the above error scenarios occur, which results in a failure. They didn't make any of the decisions which led to the failure, so they have no idea how to resolve it. Its almost always no fault of their own, and it results in a bad user experience.

My recommendation:

1. We have a setting 'metadata_checksum' which controls which checksum types the metadata are recorded with (in repomd.xml) - Optional
2. We have another setting 'preferred_package_checksum_type' (or something like that), which indicates the preference of the checksum type for the user.
3. If desired, we have 3rd setting 'strict_package_checksum_type', which does fail in the cases above, this seems less useful.

Going to your scenarios above:

2. If 'preferred_package_checksum_type' is set, generate with mixed checksum types, log a warning. If its not set, generate with whatever is upstream

3. Similar to 2

4. Yes, i'd expect the new checksum type

Your concerns:

Concerns:
- we don't have info about remote repo checksum type, we have checksum type info for each package in a RemoteArtifact.
Could this be stored read-only in the remote, and the user could then pass that to the publisher?

PR: https://github.com/pulp/pulp_rpm/pull/1674