I just got a lcms -> lcms/lcms-libs update on F-8, and found that both lcms-libs and lcms were pulled in. This is fine. But I was surprised that I can not remove lcms (and leave lcms-libs installed) after the update. Does lcms-libs really require lcms? That dependency is hardwired in the specfile still in devel. The above desirable lcms->lcms+lcms-libs upgrade feature should already be taken care of by the Obsoletes which is in -libs.
Changing version to 8 since that's where this problem was encountered. Also, the package guidelines call for fully versioned Requires on subpackages
Previously, lcms has both binaries and libaries within lcms. so while updating it to be mutlilibs compliant, I think I need to keep the binaries requirement so if for some reasons a package use lcms-devel and expect the binaires to be also present, they will be provided (same for install time and run time). The only problem I could expect is if we need another ABI incompatible version of the lcms-libs. But in this case they won't be a need to have also the binaries. Our guideline say that if such compat libaries are needed, they have to be provided with a compat-lcms package (which will not have the binaries). Is there any problem with having the binaries as a mandatory Requirement ? (expect for saving few space )? @Jon Stanley I'm not sure, I have understood well: Do you mean I need to add (from the main package): Requires: %{name}-libs = %{version}-%{release} ?
Every dependency that isn't really a dependency is a packaging bug. In addition to a little space taken, the unneeded executables are unnecessarily in everyone's $PATH, and the main lcms package brings in dependencies that lcms-libs does not have (at least libjpeg, libtiff, zlib). If lcms-devel requires the executables to be present, by all means, add the dependency there. At this point I think the right thing to do is to post to fedora-devel about the split and tell maintainers of dependent packages to see if they need to add explicit "Requires: lcms" (ie. if their package uses some of the executables), and prepare to drop the main package dependency from -libs for I'd say F-10. And add a comment to the specfile why the dependency is there for the time being. Actually I think these steps should have been done _before_ the split package hit any branches. Moving version back to Rawhide - perhaps it's better to leave older distros alone because as you say there's a window of backwards incompatibility which shouldn't be needlessly inflicted on released distro versions.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
sorry for the late answear, I've hit a bug which prevented me to evaluate the fix in time for F-10. The fixed with http://koji.fedoraproject.org/koji/taskinfo?taskID=1212896 mail send in fedora-devel ml along with the related maintainers cc'ed