Am Freitag, 30. September 2011, 11:10:27 schrieb Tom Callaway: > On 09/28/2011 11:00 PM, Richard W.M. Jones wrote: > > I checked the source code, and unison sends a header which contains > > the current major version number of the software (where "major > > version" is a string, currently "2.40"). If the major versions of > > each end don't exactly match, unison aborts. It would be possible, > > albeit complicated, to combine all versions of unison together somehow > > and switch on the major version. > > Well, while I admit that merging all the various unison protocols into a > single binary is a non-trivial task, especially if upstream isn't > interested in that level of change, it might be possible to do something > like this: > > Write a simple program which simply asks the other end to establish a > connection for the sole purpose of detecting the major version string, > then attempts to call out for a binary that could be used to actually > establish that connection. It could also do connection caching so that > only the first query attempt is necessary, future attempts would simply > pull the known type from the cache and use that, only if that failed > would it fall back to running detection. so many creative ideas ;) But I think such a program would be confusing to users: When someone wants to install unison, he expects the package will install unison and a menu entry. And not a unison version guessing tool. Also I can't imagine what will the user interface look like. > > This way, we could continue with the separate packages for older > versions of unison, with this "smart" binary in the main, current > package. If the smart binary can't find a compat version that it needs, > it can prompt the user to install "unisonNNN". > > ~tom > > == > Fedora Project Greg
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
