There is a version 2.27.29 of unison, ready to replace the 2.17.1-r1 currently in portage. As that's the version you get when you download a windows client, and as the first two parts of the version number have to agree for interaction, having that version available in portage seems highly desirable to me. Since the "latest stable", 2.13.16, is heavily outdated and 2.17.1 is a "non-stable" already, I see no reason against 2.27.29 instead of 2.17.1. Because of the incompatibilities between different versions of unison, I'd suggest to SLOT them, i.e. SLOT=2.27 in this case. I'd create /usr/bin/unison-${SLOT} as this is the only file installed apart from documentation. By stating servercmd=/usr/bin/unison-2.27 in their profiles, users could make sure to use a compatible version over ssh. You could make an eselect module for this, but perhaps always symlinking the latest version after updates would be enough. Maybe you want to create new slotted revisions of other versions as well, like 2.17 or the stable 2.13. I created a new ebuild for 2.27.29, simply copying the 2.17.1-r1 one, disabling the io patch (which is a backport according to ChangeLog) and changing the dobin into a newbin to create the versioned binary file. This does not include any management for the /usr/bin/unison symlink yet. Otherwise everything works well so far, compiles and is usable.
Created attachment 123075 [details] unison-2.27.29.ebuild I remembered the alternatives eclass and used it to beautify my ebuild.
Created attachment 123076 [details] unison-2.17.1-r2.ebuild This is a slotted version of unison-2.17.1-r1.ebuild
Created attachment 123077 [details] unison-2.13.16-r1.ebuild This is a slotted version of unison-2.13.16.ebuild
Created attachment 123078 [details, diff] diff from unison-2.17.1-r1.ebuild to unison-2.27.29.ebuild And in case some admin prefers patches instead of complete ebuilds, here is at least one containing both the slotting and the version bump. The other revision bumps only contain slotting modifications along the same lines.
I would like to see the latest version of unison made available, as I'm having problem compiling 2.17.1.
Unison 2.17.1-r1 used to crash whenever I pressed Diff for a file modified at both ends. I could now verify this problem has disappeared in 2.27.29. Please make this new version available in the portage tree.
I'd also like to have 2.27.29 in our tree :)
(In reply to comment #7) > I'd also like to have 2.27.29 in our tree :) > Wolfram, if you want to take/help with maintainership, you're more than welcome ;) I can give you an hand wrt ocaml stuff with unison, but as I'm not using it, it'd probably lead to poor QA if I maintain it through ml herd.
net-misc/unison-2.27.48 works by simply renaming the attached 2.27.29 ebuild.
There has been a new release, unison-2.27.57, and it has been declared stable - finally!
(In reply to comment #10) > There has been a new release, unison-2.27.57, and it has been declared stable - > finally! That's great news! My ebuild for 2.27.29 works well after renaming. Of course the beta warning in pkg_setup should be removed.
Created attachment 141876 [details] unison-2.27.57.ebuild This ebuild corresponds to Unison's newest stable version (mentioned in a previous comment of this bug report). It has been tested on a x86 architecture.
bumped, thanks
How about the SLOTting suggested in this report here? Was there a good reason not to include this, or should I reopen or file a new report in order to track that feature request?
(In reply to comment #14) > How about the SLOTting suggested in this report here? Was there a good reason > not to include this, or should I reopen or file a new report in order to track > that feature request? > is that really needed now that its considered stable upstream ? is there a real need to use old versions ?
(In reply to comment #15) > is that really needed now that its considered stable upstream ? > is there a real need to use old versions ? I could imagine several scenarios where people might be forced to use outdated versions: * Other distros only providing older versions. Debian e.g. has 2.9 and 2.13. * Centrally managed systems with no super user access for individuals and no updates yet by system admins. This includes some office Windows setups. * Systems where update would break other things. We all know how involved the dependencies between ocaml, lablgl, lablgtk and unison are, so updating one usually requires updating all. When there are apps around using some of these other libs, updating unison might not be an option. * Large organisations where it is infeasible to update all PCs simultaneously. Another strong reason is that the next round of unison improvements is likely to be incompatible yet again, so once you have this SLOTted, you'll not have to worry about which version to install in order to not break thigs for current users. Therefore I'd rather switch to a SLOTted ebuild now, when there is a big step in the stable version number so people are more likely to pay closer attention as to what the log says, than SLOTting in some revision bump in the future. I have to admit that none of the scenarios described above actually applies to me. I only know I'm going to keep this SLOTted, as I personally like the idea that I can update any node without my network going out of sync for any prolonged period of time. If I could drop my local ebuilds, I'd be glad.
fair enough, but that would mean also providing a simple way of switching versions (like an eselect module as you suggested) which I currently dont have the time to write :( so if you could provide one, I could add it. (and yes, please open a new bug) or perhaps would the alternatives symlink be enough ? perhaps and it'd be simpler. also, what would happen if I install the slotted version and the then non slotted one ? (and also what would happen the other way ?) will the symlinking work (ie, no collision installing the old version over the symlink and the non slotted version not erased by the symlink) ? it's not as if the previous unison ebuilds were slot aware :(
(In reply to comment #17) > fair enough, but that would mean also providing a simple way of switching > versions (like an eselect module as you suggested) which I currently dont have > the time to write :( so if you could provide one, I could add it. > (and yes, please open a new bug) > > or perhaps would the alternatives symlink be enough ? perhaps and it'd be > simpler. I guess the alternatives symlink is enough. This way you'll always run the latest version when you enter "unison", but still can access any installed version using the full binary name. An eselect module would still be handy for those cases where a server admin wants to install a new version without requiring all its clients to update their configs, thus having the simple name refer to the older version. I'll adapt app-admin/eselect-vi later on, that seems simple enough, and gets even simpler for unison. But as this would become a separate package that only makes sense once slotted unison is in place, I'd file a separate bug for that and have it depend on this one here. > also, what would happen if I install the slotted version and the then non > slotted one ? The non-slotted ebuild overwrites the unison symlink with its unison binary. The slotted versions are still available through their versioned binaries. > (and also what would happen the other way ?) The slotted ebuild creates the symlink, overwriting the previous binary. The non-slotted version will become pretty much useless, which is why my ebuild contains some elog lines in pkg_setup suggesting removal of those. > will the symlinking work (ie, no collision installing the old version over the > symlink and the non slotted version not erased by the symlink) ? That's not the way it would be. On the other hand, I can imagine no sensible way for the slotted ebuild to not overwrite the non-slotted binary. You could use a different name or path for the ebuild, or have the ebuild move the non-slotted binary, but all of these feel like really ugly hacks. The way I had planned, you'd update, and from that moment on you'd have the latest version of unison available. So far pretty much like a non-slotted update. Automatic cleaning wouldn't remove the slot 0 predecessor, so if you ignore the elog, at the worst you'd have one useless package consisting of about ten doc files. > it's not as if the previous unison ebuilds were slot aware :( That's why I suggested providing slotted ebuilds for commonly used versions. Right now I guess 2.17.1 and 2.13.16 would be enough.
(In reply to comment #18) > I'll adapt app-admin/eselect-vi later on. But as this would become a separate > package that only makes sense once slotted unison is in place, I'd file a > separate bug for that and have it depend on this one here. Filed bug 207746 for the eselect module.
Would it be possible to get the SLOTed 2.13.16 ebuild in portage. This is the version Ubuntu has in it's repo so it would be very useful to have also. I also wanted to say thank you to everyone involved with this. A very useful feature.
(In reply to comment #20) > Would it be possible to get the SLOTed 2.13.16 ebuild in portage. This is the > version Ubuntu has in it's repo so it would be very useful to have also. yep this is planned for when eselect-unison will have reached the same ~arch keywords than unison reopening as there is Martin's ebuild attached here
slotted 2.13.16 eventually in the tree
