https://bugzilla.redhat.com/show_bug.cgi?id=1171129 --- Comment #15 from Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> --- It is mostly OK. But... Obsoleting a package that continues to exist in the destribution is a packaging bug. (See today's notification on devel@xxxxxxxx.o about obsoleted packages still remaining in the repos and the reqest to the maintainers to fix it.) If you introduce an Obsoletes, there must exist a plan to remove the obsoleted package. Introducing an Obsoletes against a package that is planning to stay in the distribution is not really an Obsoletes but rather a very aggressive version of a Conflicts, and therefore not allowed. You have a couple of options: A. Agree with the maintainer of radiusclient-ng that there will be an updated radiusclient-ng package that removes the radiusclient-ng-utils subpackage. Then your latest version of the freeradius-client.spec is OK. Except you will know the first version-release of radiusclient-ng that has dropped the -utils subpackage and you can use a versioned Obsolete. B. Agree with the maintainer of radiusclient-ng that the entire radiusclient-ng will be retired. You will then know the last version of radiusclient-ng that existed before it was retired, and you can use a versioned Obsoletes. In this case you should also add Obsoletes for radiusclient-ng and radiusclient-ng-devel. C. Agree with the maintainer of radiusclient-ng that both radiusclient-ng-utils and freeradius-client-utils will both provide the utilities and that both will introduce alternatives and how. The radiusclient-ng-utils package that introduces the alternatives must have a proper %pre that deletes the files that will be replaced by alternatives to upgrade properly and you should not have an Obsloetes for the radiusclient-ng-utils in the freeradius-client-utils package. You should insted have a versioned Conflicts against versions of radiusclient-ng-utils earlier than the first version-release that adds the alternatives (i.e. versions no longer present in the distribution). D. You remove the freeradius-client-utils subpackage from the freeradius-client source package and only build the freeradius-client and freeradius-client-devel packages. This will introduce the new package without any conflicts with the existing package. If you are unable to make an agreement with the maintainer of radiusclient-ng at this time, you can if you wish do option D first and then change to A, B or C at a later point in time when an agreement has been reached. If you have been trying to contact the maintainer of radiusclient-ng without success, then follow the procedure outlined in the Policy for Non-responsive Maintainers: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review