Hi,
Anyone want to review this one: https://bugzilla.redhat.com/show_bug.cgi?id=734531
I'm sure a lot of Fedora users are awaiting this update.
Regards, Greg
On Tue, Sep 27, 2011 at 05:13:46PM +0200, Gregor Tätzner wrote:
Hi,
Anyone want to review this one: https://bugzilla.redhat.com/show_bug.cgi?id=734531
I'm sure a lot of Fedora users are awaiting this update.
Questions ...
Are we going to obsolete these packages:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Adding a new package every time upstream has a slight wobble over the Unison protocol just seems wrong to me, and I'm sure there's got to be a better way to package this.
Did you look at what Debian are doing?
Rich.
Am Dienstag, 27. September 2011, 19:46:08 schrieb Richard W.M. Jones:
On Tue, Sep 27, 2011 at 05:13:46PM +0200, Gregor Tätzner wrote:
Hi,
Anyone want to review this one: https://bugzilla.redhat.com/show_bug.cgi?id=734531
I'm sure a lot of Fedora users are awaiting this update.
Questions ...
Are we going to obsolete these packages:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
What do you mean by obsolete? Remove them? What's about the people using older releases?
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Something like a single multi-version unison package is possible? And is it really worth it? Sounds like a lot of work.
Adding a new package every time upstream has a slight wobble over the Unison protocol just seems wrong to me, and I'm sure there's got to be a better way to package this.
Did you look at what Debian are doing?
Yeah, in each distribution they have only one package with the recent (in terms of debian) version. It's splitted up in unison and unison-gtk, though. I dont' like it.
Rich.
Greg
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility.
Isn't there a general policy "split into many rpms, when possible"?
Having a single executable would be great (like rsync), but that is an upstream issue.
On Wed, Sep 28, 2011 at 08:55:43AM +0200, Roberto Ragusa wrote:
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility.
Isn't there a general policy "split into many rpms, when possible"?
Having a single executable would be great (like rsync), but that is an upstream issue.
They don't all need to be in separately named packages. It's not beyond the realm of possibility for us to package up multiple versions of the source into one unison package.
TBH I'd like to hear what FESCO have to say about this, because AFAIK there is no other package in the whole of Fedora which is packaged this way.
Rich.
On Wed, 28 Sep 2011 10:15:54 +0100 "Richard W.M. Jones" rjones@redhat.com wrote:
On Wed, Sep 28, 2011 at 08:55:43AM +0200, Roberto Ragusa wrote:
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility.
Isn't there a general policy "split into many rpms, when possible"?
Having a single executable would be great (like rsync), but that is an upstream issue.
They don't all need to be in separately named packages. It's not beyond the realm of possibility for us to package up multiple versions of the source into one unison package.
Well, typically we put one upstream source archive per package. What does putting them all in one package gain us? Having to update all of them if any of them need an update?
TBH I'd like to hear what FESCO have to say about this, because AFAIK there is no other package in the whole of Fedora which is packaged this way.
The problem here is that upstream has no desire to keep a common protocol, so you need the exact version on both ends. (If I recall correctly). So, if you have say a debian box with version foo, you need version foo on the fedora machine to talk to it. In the past this has been done with multiple packages where 'yum install unison' gets you the latest, and if you need an older version you can manually pick and install that one.
So, not sure how better to solve this problem than with compatibility packages.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2011 10:20 AM, Kevin Fenzi wrote:
The problem here is that upstream has no desire to keep a common protocol, so you need the exact version on both ends. (If I recall correctly). So, if you have say a debian box with version foo, you need version foo on the fedora machine to talk to it. In the past this has been done with multiple packages where 'yum install unison' gets you the latest, and if you need an older version you can manually pick and install that one.
So, not sure how better to solve this problem than with compatibility packages.
Is it not at all possible to determine the protocol version of the other end? It seems like this is a solvable problem.
~tom
== Fedora Project
On Wed, Sep 28, 2011 at 12:10:32PM -0400, Tom Callaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2011 10:20 AM, Kevin Fenzi wrote:
The problem here is that upstream has no desire to keep a common protocol, so you need the exact version on both ends. (If I recall correctly). So, if you have say a debian box with version foo, you need version foo on the fedora machine to talk to it. In the past this has been done with multiple packages where 'yum install unison' gets you the latest, and if you need an older version you can manually pick and install that one.
So, not sure how better to solve this problem than with compatibility packages.
Is it not at all possible to determine the protocol version of the other end? It seems like this is a solvable problem.
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.
I was thinking of something slightly simpler: a single 'unison' package that contained several binaries, like /usr/bin/unison227, /usr/bin/unison (symlink to latest).
Rich.
On Wed, 28 Sep 2011 22:00:40 +0100 "Richard W.M. Jones" rjones@redhat.com 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.
I think you can run it with a switch or compile time option to make it pass the full version so you could have unison-2.40 and unison-99 on the remote end and it would start the right one.
I was thinking of something slightly simpler: a single 'unison' package that contained several binaries, like /usr/bin/unison227, /usr/bin/unison (symlink to latest).
That does help with needing re-reviews and names and such, but it doesn't help in that you have to update everything everytime a new version comes out.
kevin
On 2011-09-28 14:15, Kevin Fenzi wrote:
On Wed, 28 Sep 2011 22:00:40 +0100 "Richard W.M. Jones"rjones@redhat.com wrote:
I was thinking of something slightly simpler: a single 'unison' package that contained several binaries, like /usr/bin/unison227, /usr/bin/unison (symlink to latest).
That does help with needing re-reviews and names and such, but it doesn't help in that you have to update everything everytime a new version comes out.
One build could produce a package for each version. The packages' n-v-rs could then be maintained independently. I am not sure how bodhi would behave in such a case, though.
This most certainly is not optimal; I'm simply throwing the idea over the wall.
On Sep 29, 2011, at 1:13 AM, Garrett Holmstrom wrote:
One build could produce a package for each version. The packages' n-v-rs could then be maintained independently. I am not sure how bodhi would behave in such a case, though.
This most certainly is not optimal; I'm simply throwing the idea over the wall.
The build system would reject this. Every produced rpm has to have a unique n-v-r.
- jlk
On Thursday, 29 September 2011 at 15:38, Jesse Keating wrote:
On Sep 29, 2011, at 1:13 AM, Garrett Holmstrom wrote:
One build could produce a package for each version. The packages' n-v-rs could then be maintained independently. I am not sure how bodhi would behave in such a case, though.
This most certainly is not optimal; I'm simply throwing the idea over the wall.
The build system would reject this. Every produced rpm has to have a unique n-v-r.
One solution would be to make per-version subpackages conditional via macros and build only the one that has been updated.
Example: we have unison-2.9-1 package which produces unison-2.9-1 unison28-2.8-2 unison21-2.1-5
We want to update unison28, so the next build of unison-2.9-2 produces only: unison28-2.8.1-1
What do you think?
Regards, Dominik
On Thu, Sep 29, 2011 at 06:50:04PM +0200, Dominik 'Rathann' Mierzejewski wrote:
Example: we have unison-2.9-1 package which produces unison-2.9-1 unison28-2.8-2 unison21-2.1-5
We want to update unison28, so the next build of unison-2.9-2 produces only: unison28-2.8.1-1
What do you think?
This is too complex and makes automatic mass rebuilds more complicated.
Kind regards Till
On Sep 29, 2011, at 12:50 PM, Dominik 'Rathann' Mierzejewski wrote:
One solution would be to make per-version subpackages conditional via macros and build only the one that has been updated.
Example: we have unison-2.9-1 package which produces unison-2.9-1 unison28-2.8-2 unison21-2.1-5
We want to update unison28, so the next build of unison-2.9-2 produces only: unison28-2.8.1-1
What do you think?
The build system would not return a sub package from an older build when you go to compose the tree. Instead you'd only get the sub packages that are in the latest build. The old ones will disappear.
- jlk
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.
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 01:38 PM, Gregor Tätzner wrote:
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.
Eh, I suppose I wasn't thinking of the GUI side of things. Arguably the user isn't expecting to deal with Unison Protocol Hell either.
Also I can't imagine what will the user interface look like.
Well, it could be minimal, but I'm not volunteering to do it.
~tom
== Fedora Project
On Wed, Sep 28, 2011 at 2:15 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Wed, Sep 28, 2011 at 08:55:43AM +0200, Roberto Ragusa wrote:
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility.
Isn't there a general policy "split into many rpms, when possible"?
Having a single executable would be great (like rsync), but that is an upstream issue.
They don't all need to be in separately named packages. It's not beyond the realm of possibility for us to package up multiple versions of the source into one unison package.
This isn't helpful for the user's of the package. An update to any version of unison would mean an updated packages for all versions of unison.
TBH I'd like to hear what FESCO have to say about this, because AFAIK there is no other package in the whole of Fedora which is packaged this way.
Probably more of an FPC question. /me dons FPC hat
IIRC, this was discussed on the mailing list a long time ago because unison used to package only the latest version (much like Debian does now). Once we were made aware that the upstream for unison was not interested in maintaining wire compatibility between any versions of their software, we decided that separate packages for compatibility would be the best solution that we could manage. Is it suboptimal? Yes. Is there a solution with a better set of tradeoffs? We haven't found one yet (including the proposal which you've made which we've already discussed and discarded).
-Toshio
Am Mittwoch, 28. September 2011, 11:15:54 schrieb Richard W.M. Jones:
On Wed, Sep 28, 2011 at 08:55:43AM +0200, Roberto Ragusa wrote:
On 09/27/2011 07:46 PM, Richard W.M. Jones wrote:
https://admin.fedoraproject.org/pkgdb/acls/name/unison213 https://admin.fedoraproject.org/pkgdb/acls/name/unison227 https://admin.fedoraproject.org/pkgdb/acls/name/unison
Instead of introducing yet another variation, can we somehow create a single 'unison' package which covers all of the protocol variants?
Why should I install all versions if I only want the recent one? Or the xxx one, for compatibility.
Isn't there a general policy "split into many rpms, when possible"?
Having a single executable would be great (like rsync), but that is an upstream issue.
They don't all need to be in separately named packages. It's not beyond the realm of possibility for us to package up multiple versions of the source into one unison package.
TBH I'd like to hear what FESCO have to say about this, because AFAIK there is no other package in the whole of Fedora which is packaged this way.
Rich.
Any news from the FESCO team? What's the conclusion of this discussion?
Regards, Greg
On Mon, 3 Oct 2011 19:22:28 +0200 Gregor Tätzner gregor@freenet.de wrote:
Any news from the FESCO team? What's the conclusion of this discussion?
No one has officially asked fesco...
Please file a ticket what you actually want to ask fesco here?
https://fedorahosted.org/fesco/newtplticket
Personally, I think that barring upstream waking up and deciding to support different versions being able to talk to each other, we are setup the best we can.
I'm not sure how we could better setup the packages... whats the actual proposal here? All of the versions in one package is not a good solution, IMHO.
kevin
On Mon, Oct 03, 2011 at 11:32:18AM -0600, Kevin Fenzi wrote:
On Mon, 3 Oct 2011 19:22:28 +0200 Gregor Tätzner gregor@freenet.de wrote:
Any news from the FESCO team? What's the conclusion of this discussion?
No one has officially asked fesco...
Please file a ticket what you actually want to ask fesco here?
It's a Fedora Packaging issue, and it was discussed a long time ago:
https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01229.html
The point I wanted to raise is whether we should revisit this issue and if we can package unison better.
I'm not sure how we could better setup the packages... whats the actual proposal here? All of the versions in one package is not a good solution, IMHO.
Agreed. But going through a new package process every time upstream releases a new version is also not great.
Rich.
Am Montag, 3. Oktober 2011, 20:26:11 schrieb Richard W.M. Jones:
On Mon, Oct 03, 2011 at 11:32:18AM -0600, Kevin Fenzi wrote:
On Mon, 3 Oct 2011 19:22:28 +0200
Gregor Tätzner gregor@freenet.de wrote:
Any news from the FESCO team? What's the conclusion of this discussion?
No one has officially asked fesco...
Please file a ticket what you actually want to ask fesco here?
It's a Fedora Packaging issue, and it was discussed a long time ago:
https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01229.html
The point I wanted to raise is whether we should revisit this issue and if we can package unison better.
I'm not sure how we could better setup the packages... whats the actual proposal here? All of the versions in one package is not a good solution, IMHO.
Agreed. But going through a new package process every time upstream releases a new version is also not great.
Rich.
Another idea: Just put in the package *unison* the latest release and when a new shiny version has been released we provide a compat version, so move unison to *unisonXYZ* and update the *unison* package regularly.
I suppose this would spare the review process every release?
Greg
On Mon, Oct 03, 2011 at 10:05:09PM +0200, Gregor Tätzner wrote:
Another idea: Just put in the package *unison* the latest release and when a new shiny version has been released we provide a compat version, so move unison to *unisonXYZ* and update the *unison* package regularly.
I suppose this would spare the review process every release?
As long as a compat package wasn't desired for every release.
I've only evaluated plans based on what other people have told me about unison but I believe the problem was that we do end up wanting a compat package (and also a forward compat package) for just about all unison releases. Since unison won't make wire-compatibility guarantees, if you have unison-1 on latest Debian stable, unison-2 on Ubuntu, unison-3 on Fedora-14, unison-4 on Fedora-15, etc, someone wants to be able to manage files between some combination of any of these. So you need to have compat packages that can make that possible.
-Toshio
Am Dienstag, 27. September 2011, 17:13:46 schrieb Gregor Tätzner:
Hi,
Anyone want to review this one: https://bugzilla.redhat.com/show_bug.cgi?id=734531
I'm sure a lot of Fedora users are awaiting this update.
Regards, Greg
The leaves are falling and F16 is coming soon. Neither we have a new way of packaging unison nor the current package was approved. Maybe someone could step in? What about a review swap?
Cheers, Greg
-
Dominik 'Rathann' Mierzejewski -
Garrett Holmstrom -
Gregor Tätzner -
Jesse Keating -
Kevin Fenzi -
Richard W.M. Jones -
Roberto Ragusa -
Till Maas -
Tom Callaway -
Toshio Kuratomi