On Thu, Apr 17, 2008 at 4:00 PM, Stephen Warren <s-t-rhbugzilla@xxxxxxxxxxxxx> wrote: > * The "first" package by some sorting order that matches there is a sorting order when picking between different packages that provide the same thing to fill a provides dep.. typically it is expressed as "shortest" name wins. The most common case is virtual provides from packages with significantly different names. Now the unison case.. is extremely special, in that you are fooled into thinking that the two unison packages are suppose to compare in the same versioning space. They are not. The packagenaming being used for unison is a hack and you should not intuit that the numbers in the package name suggest a version comparison. Stop thinking about them as a lower version and a higher version of the same codebase. Think of them as codebase forks. The unison developers..in their infinite wisdom have decided that they don't actually want to worry about backwards compatibility between client versions, so if you need to talk across the network to different machines you need to be sure you have the same version of unison available on both machines or the magic doesn't work. The horrible horrible package naming for unison that we have is a result of that upstream decision to make sure people who want to use unison can be sure they have the right versions of unison installed to communicate to machines running other operating systems. The package naming in the case of unison is done deliberately to break how version comparison in the package system is suppose to work. It's a corner case... that needs to die. Adding more logic at the packaging layer to support what is really upstream's inability to provide adequate protocol versioning support is wasted effort. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
