Bug 433915

*** Bug 433742 has been marked as a duplicate of this bug. ***

Renaming the binary is probably a bad idea, in the case that this package
installed on the server side, as the client will try to call "unison"
on the server.

Renaming the binary is required so that the unison and unison2.13 packages can
co-exist on the same machine.

On other systems that support parallel installation of multiple versions of
Unison (e.g. Cygwin, and I have to assume Debian/Ubuntu too), this is the way it
works, so it's not remotely unexpected to users of Unison.

Similarly, Unison itself supports the "addversiono" option that'll attempt to
invoke e.g. unison-2.13 on the server instead of plain unison. In this package,
the binary is renamed to match what Unison will attempt to invoke (when using
this option.)

In my opinion, this whole thing has been approached from the wrong perspective.
 When Fedora 8 was released, the Unison package was version 2.13.  Until Fedora
9 is released, Unison 2.13 should still be the default version.  The additional
package should be unison2.27.

People expect things to break when they upgrade from Fedora 8 to Fedora 9, but
they don't expect things to randomly break when they check for updates to Fedora 8.

By the way, if people wanted 2.27 so badly, why couldn't they just do
--enablerepo=development?

Andrew,

Yes, I totally agree. However, it doesn't seem like discussion on Fedora-devel
was moving in the direction of making plain old "unison" continue to be 2.13,
hence I'm trying to get 2.13 back into F8 ASAP.

FYI, my long term goals would be a situation as follows:

For *all* versions of Unison, there will be a "versioned" package unison2.13,
unison2.27 etc.

There will also be an "unversioned" or "meta" package representing the moving
latest version.

This main unison package could contain nothing but the following symlink that
moves based on latest version:

/usr/bin/unison -> /usr/bin/unison-${version}

and a Requires ensuring that the relevant "versioned" package is installed.

This allows all of:

* People can ensure a specific version is installed by installing the versioned
package, with no special cases for whatever the latest version is (since there
will be a versioned package for the latest version too)

* People only interested in interoperability with other Fedora installations at
the same release level can simply install "unison" and have it upgrade whenever
(this still allows us to implement whatever policy we want regarding when to
point this "meta"-package at new versions.)

* People can have N different specific versions installed too, for
interoperability with multiple other systems.

The only issue I see is that if somebody installs plain "unison", and this gets
upgraded, then the old "versioned" package will get left behind. Perhaps the
main unversioned package should just have a copy of the latest app, and not be a
symlink/requires; that would solve this at the potential expense of having two
copies of the latest if explicit versioned packages are installed.

Perhaps if there's further discussion of the above, we should do it on the
mailing list, so the bug doesn't get full up and distract from review?

On second thoughts, I think we should have:
unison2.13
unison2.27
and use the alternatives system to switch the /usr/bin/unison link.

How about this, alternatives, upgrade path, and all:

Spec URL: http://avon.wwwdotorg.org/downloads/unison2.13/unison2.13.spec
SRPM URL:
http://avon.wwwdotorg.org/downloads/unison2.13/unison2.13-2.13.16-5.fc8.src.rpm

Spec URL: http://avon.wwwdotorg.org/downloads/unison2.27/unison2.27.spec
SRPM URL:
http://avon.wwwdotorg.org/downloads/unison2.27/unison2.27-2.27.57-3.fc8.src.rpm

Description:
Unison is a multi-master file-synchronization tool. It allows two
replicas of a collection of files and directories to be stored on
different hosts (or different locations on the same host), modified
separately, and then brought up to date by propagating the changes
in each replica to the other.

Note that this package contains Unison version %{ver_maj}, and
will never be upgraded to a different major version. Other packages
exist if you require a different major version.

Stephen, I like this approach much better.  Thanks.

Clearing fedora-review=?. I misremembered, and thought that was the "request
review" value. Also, I was hoping Gerard would review this, but he hasn't, yet
at least.

Minor updates to fulfill Fedora's provides/obsoletes policy re: package
renaming. Also, the unison2.27 package is now split out into a separate review
request.

Spec URL: http://avon.wwwdotorg.org/downloads/unison2.13/unison2.13.spec
SRPM URL:
http://avon.wwwdotorg.org/downloads/unison2.13/unison2.13-2.13.16-7.fc8.src.rpm

Description:
Unison is a multi-master file-synchronization tool. It allows two
replicas of a collection of files and directories to be stored on
different hosts (or different locations on the same host), modified
separately, and then brought up to date by propagating the changes
in each replica to the other.

Note that this package contains Unison version %{ver_maj}, and
will never be upgraded to a different major version. Other packages
exist if you require a different major version.

Notes:
Please see bug 433742 for background on why this package was created.
Please see bug 435578 for a review request for package unison2.27

There's one rpmlint warning, which is expected; the unison2.27 package provides
plain "unison", so that users who just say "unison" get the latest version.

Just in case anybody is holding off reviewing this because they aren't sure
whether replacing the existing unison package is A Good Thing, the existing
maintainer said this:

Sorry for taking so long, but currently I have other problems to deal
with. You can take over maintainership of the unison packages if you
want. I can also co-maintain the packages, but I don't know when I have
the time to review them. I presume you have made some changes concerning
alternatives?

ok, since no one else is wanting to review, I will give it a shot. ;) 

Look for a full review here in a few. 

Humm. Before I do a full review here... shouldn't this package be named: 

unison213 ?

See:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-48ca801d3f8b9f46713343760949349fba78e644

"Note that we do not use delimiters in the name in this situation, we remove the
period '.' from the version number and attach it to the name."

Re: naming unison213. Yes, those rules do apply.

That's unfortunate, since it makes the package name less meaningful to me, and
inconsistent with other distros. Hopefully there won't be a version 21.3,
because then the package names will collide. 

But, since these are the rules, I'll rename the package. 

It also states that there should be a package names plain "unison" instead of
"unison227". I'm not convinced I like that idea, since that package will
continually get upgraded with incompatible versions, which is what triggered
adding the new packages in the first place. Would an exception be OK for the
"latest" package name due to the way upstream works?

Alternatively, one could create a compat-unison-2.13 package.

The reason I don't like having:

unison2.13 and unison

as opposed to:

unison2.13 and unison2.27

is that in the former case, if unison switches from packageing 2.27 to a
hypothetical 2.28 that's not compatible, we'll have to create
(compat-)unison2.27, and users will have to manually install that. If they get a
"versioned" package from the get-go in all cases, then they won't have to do this.

Yeah, I agree with Stephen's rationale in comment #16 overall. 

The remaining question in my mind is: Should there be any kind of Provides for
"unison" so users who don't care about versions can simply install it. 
That would introduce some annoying corner cases however:

1. Current installs that have 'unison' installed. 

I would guess we would make the newest version in each dist
"Provides: unison = %{version}-%{release}"
This would upgrade current installs to the newest version for that dist. 

2. Dist upgrades (ie, from f8 to f9 or f9 to f10)

The above would mean that if you had the newest unison package installed, 
you could be upgraded to an incompatible version on dist upgrade. 
Of course users could then simply install the 'unisonXYZ' to maintain
compatibility. 

That all could be too much trouble however. Might be better to just have users
install the exact unison package they want specifically. Thoughts? 
Or a more clever way to handle things?

Anyhow, Stephen: Can you spin up a new 'unison213' package? 

Kevin Fenzi wrote:
> 1. Current installs that have 'unison' installed. 
> 
> I would guess we would make the newest version in each dist
> "Provides: unison = %{version}-%{release}"
> This would upgrade current installs to the newest version for that dist. 

Yes, that's already in the specs. The new packages obsolete the existing
"unversioned" unison package in order to get it off the system so that the
alternatives links set up by the new packages will work.

> 2. Dist upgrades (ie, from f8 to f9 or f9 to f10)
> 
> The above would mean that if you had the newest unison package installed, 
> you could be upgraded to an incompatible version on dist upgrade. 
> Of course users could then simply install the 'unisonXYZ' to maintain
> compatibility.

Really? If I "yum install unison", I'll get "unison227-XXX" with these new
packages. Given this, won't unison227 be the thing yum looks for on
update/upgrade, and hence will stay installed. Does a package that provides
something really get removed and replaced with a different package just because
something different provides that?

New spec/SRPM coming up soon, once mock has finished updating my build root.
Sorry to take so long - had company visiting and a needy baby...

Spec URL: http://avon.wwwdotorg.org/downloads/unison213/unison213.spec
SRPM URL:
http://avon.wwwdotorg.org/downloads/unison213/unison213-2.13.16-8.fc8.src.rpm

Note to self: Remember to file a bug re: ExcludeArch: PPC64 (see
FE-ExcludeArch-ppc64, bug 238953) because the ocaml native compiler isn't
available on PPC64.

>Really? If I "yum install unison", I'll get "unison227-XXX" with these new
>packages. Given this, won't unison227 be the thing yum looks for on
>update/upgrade, and hence will stay installed. Does a package that provides
>something really get removed and replaced with a different package just because
>something different provides that?

No, it shouldn't unless there are Obsoletes... 

>Note to self: Remember to file a bug re: ExcludeArch: PPC64 (see
>FE-ExcludeArch-ppc64, FE-ExcludeArch-ppc64) because the ocaml native compiler
>isn't available on PPC64.

It should be as of the last few weeks... so no need for that. ;) 

Look for a review here in a bit. 

OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPL+)
See below - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
a79bf5f4ebf2a1eaf15b1ac97f827374  unison-2.13.16.tar.gz
a79bf5f4ebf2a1eaf15b1ac97f827374  unison-2.13.16.tar.gz.orig
See below - Package needs ExcludeArch
OK - BuildRequires correct
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package has rm -rf RPM_BUILD_ROOT at top of %install

OK - Package is a GUI app and has a .desktop file

OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
See below - No rpmlint output.
See below - final provides and requires are sane.

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should have dist tag

Issues:

1. Seems like all the source files here just say:
 Copyright 1999-2004 (see COPYING for details)
COPYING is just a copy of the GPL, so this would make the
project "GPL+" (ie, any version of the GPL).
Perhaps you can clarify with upstream what they intend here?

2. ocaml should now be available on ppc64, so you shouldn't need
to exclude that anymore. I did a scratch build here and it built fine on
ppc64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=518984

3. rpmlint says:

unison213.x86_64: W: obsolete-not-provided unison

This can be ignored as this is the compat/lower version for the release.

> 1. Seems like all the source files here just say:
> ... license ...
> Perhaps you can clarify with upstream what they intend here?

Sure; I'll fire of an email...

> 2. ocaml should now be available on ppc64, so you shouldn't need...

Cool! Gerard added the Exclude when unison got rebuilt a month or so ago. I
guess he was unlucky and just missed it being available! I'll fix this once I
hear back on the license to batch up any required spec changes.

Thanks *very* much for the review.

Re: The license. Isn't COPYING GPLv2, not just GPL? Also, COPYING states that if
the source file states "or later", then you have that option, then otherwise
not. Hence, why I chose GPLv2, not GPLv2+.

Anyway, I'm in the process of confirming with upstream what they actually did
intend.

Note to self: OCAML is only available on ppc64 in devel/F-9, not F-8/F-7.

Upstream says this:

Well, the true answer is that we wanted an open-source license for all  
the usual reasons, chose GPLv2 because it was standard at the time,  
and then forgot about it.  :-)

I agree that the current state of affairs looks like "v2 and not  
later," strictly speaking.  If this is preventing anyone from using or  
improving Unison, though, I'd be willing to consider changing.

To avoid turning the Unison list into a GPL discussion forum, could  
people please communicate their opinions about this to me off-list?

Thanks,

     - Benjamin

Well, because the GPL (all versions) includes: 

"If the Program does not specify a version number of this License, you may
choose any version ever published by the Free Software
Foundation."

The correct license tag here is "GPL+", ie, ANY version of the GPL, not just
GPLv2. So, GPLv1, GPLv2, GPLv3, or any other version that exists or may exist. 

Upstream has acknowledged GPL+ and is OK with it. I'll respin a new SRPM with
this and the ExcludeArch fix hopefully tonight, depending on headache...

Updated package:

Spec URL: http://avon.wwwdotorg.org/downloads/unison213/unison213.spec
SRPM URL:
http://avon.wwwdotorg.org/downloads/unison213/unison213-2.13.16-9.fc8.src.rpm

Excellent. I see no further blockers here, so this package is APPROVED. 

Might I suggest that you wait until the unison227 package is approved before
importing this one? At the same time you will need to follow the end of life
procedure on the plain 'unison' package and drop it out of things. 

I will try and review the unison227 package soon, unless someone beats me to it. 

> Might I suggest that you wait until the unison227 package is approved before
> importing this one? At the same time you will need to follow the end of life
> procedure on the plain 'unison' package and drop it out of things.

Absolutely. I assume I don't start any of the EOL steps until after the new
packages have been signed and pushed to updates via bodhi?

Correct. Make sure things are pushed before the old package is end of lifed. 

New Package CVS Request
=======================
Package Name: unison213
Short Description:  Multi-master File synchronization tool
Owners: swarren,gemi
Branches: F-7 F-8 devel EL-4 EL-5
Cvsextras Commits: yes

cvs done. 

I would suggest pushing this package and the other unison one into rawhide and
letting them be there a few days before pushing the other branches, just to make
sure everything works as expected. 

This package is now in F7 stable, F8 stable, and devel, hence closing out this bug.