I don't think this is explained and named very well, but if I understand this correctly, this adds no new dependencies, merely it canonizes the existing ones. Nevertheless I'd appreciate an opt out mechanism.

I also think an opt-out may be good, but I see the value in the proposal. @ignatenkobrain, what do you think about adding an opt-out mechanism to the proposal?

Just to clarify: the idea here is that it will examine automatic dependencies and if it determines that they are a dependency on another package within the same source RPM it will strengthen them to require the same ENVR?

The only example I can come up with for needing an opt-out is something like MariaDB where a subpackage depends on libmysql.so but may be okay with using the one from the MySQL SRPM instead of the MariaDB RPM. Automatically converting this into a dependency on mariadb-libs instead of libmysql.so would be incorrect, since it should be satisfiable by either.

Definitely there would be opt-out.

+1 based on the above

How does this work with kernel, where we have multiple versions of some subpackages installed, but only one version of others?

Hmm, nevermind, I suppose opt-out is the answer there. As long as there is an opt-out, I am +1

I'm +1 as well.

+1 to the idea, but should we wait until this is implemented upstream in rpm before tying it to a release?

+1

but should we wait until this is implemented upstream in rpm before tying it to a release?

We can approve this and just check if it is done on deadlines, like we do with every other changes anyway.

After 10 days, I count the vote as (+4,0,-0) and will process this change as approved.