RPM Support

I think the root cause of the issue is the evolution of the checksum type feature.
First, only sha256 was used and it was treated as a default for publications.
Then Pulp started accepting a one-time option at publication time to have a custom checksum type.
Then Pulp started to consider the original checksum type which comes from the remote source, and the precedence was: one-time option at publish time, original checksum type, default value.
Then the configuration of checksum type became available on the repository model, and it has a default value, which is currently has higher precedence than the original checksum type. I think it is not an intentional behaviour.

I suggest to remove a default for the repository configuration and allow it to be not configured.

ttereshc wrote:

I think the root cause of the issue is the evolution of the checksum type feature.
First, only sha256 was used and it was treated as a default for publications.
Then Pulp started accepting a one-time option at publication time to have a custom checksum type.
Then Pulp started to consider the original checksum type which comes from the remote source, and the precedence was: one-time option at publish time, original checksum type, default value.
Then the configuration of checksum type became available on the repository model, and it has a default value, which is currently has higher precedence than the original checksum type. I think it is not an intentional behaviour.

I suggest to remove a default for the repository configuration and allow it to be not configured.

Docs also should be updated https://docs.pulpproject.org/pulp_rpm/workflows/create_sync_publish.html#create-a-publication

Then the configuration of checksum type became available on the repository model, and it has a default value, which is currently has higher precedence than the original checksum type. I think it is not an intentional behaviour.

Agreed.