I did a bit of experimental packaging of Unison over the weekend, and -- proving the importance of creating a mock-up -- I came to realize why my proposal was wrong: - Subpackages would have the wrong version number. eg: If the main package was unison-2.48.3-1.fc23, the Unison 2.40 branch subpackage would have been called unison240-2.48.3-1.fc23 (containing only version 2.40.x). - The current scheme actually complies with Fedora guidelines, which I didn't realize until I reread the packaging guidelines more carefully. See: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#MultiplePackages So I guess we're stuck with the old branches in separate packages as now. *However* I would still like to package upstream Unison (currently 2.48.3) by reviving the "unison" package (currently dead.package). This package would contain te latest upstream version and would break backwards compatiblity whenever upstream did. Also as there is a new version of unison227 available upstream, I will push an update for that in Rawhide shortly. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
