10:13 a.m.
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
--
Vitamin C deficiency is apauling.
12:46 p.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
2:27 p.m.
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
--
I'm QUIETLY reading the latest issue of "BOWLING WORLD" while my wife
and two children stand QUIETLY BY ...
1:55 a.m.
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.
--
Roberto Ragusa mail at robertoragusa.it
4:15 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
9:20 a.m.
On Wed, 28 Sep 2011 10:15:54 +0100
"Richard W.M. Jones" <rjones(a)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
11:10 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6DRvAACgkQPF6ZrZMFQmBHgACfYxNnc6My8HNOKZSKZ6WzxwfE
AHwAn0Fd87cZSkalgDkejkdEaj+FCfr5
=3fNF
-----END PGP SIGNATURE-----
4 p.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4:15 p.m.
On Wed, 28 Sep 2011 22:00:40 +0100
"Richard W.M. Jones" <rjones(a)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
12:13 a.m.
On 2011-09-28 14:15, Kevin Fenzi wrote:
On Wed, 28 Sep 2011 22:00:40 +0100
"Richard W.M. Jones"<rjones(a)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.
8:38 a.m.
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
11:50 a.m.
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
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:17 p.m.
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
12:30 p.m.
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
4:10 a.m.
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
6:38 a.m.
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
8:42 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Fx2AACgkQPF6ZrZMFQmCXsQCeMIpJvknLS2Lu4zPzW8C0aQnP
iaUAn1kY8sRXGA7F804+YUgcyAc/gclV
=YuY7
-----END PGP SIGNATURE-----
4:54 p.m.
On Wed, Sep 28, 2011 at 2:15 AM, Richard W.M. Jones <rjones(a)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
12:22 p.m.
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
--
Your nature demands love and your happiness depends on it.
12:32 p.m.
On Mon, 3 Oct 2011 19:22:28 +0200
Gregor Tätzner <gregor(a)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
1:26 p.m.
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(a)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
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
3:05 p.m.
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(a)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
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
--
Life is cheap, but the accessories can kill you.
4:31 p.m.
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
5:17 a.m.
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
--
The older a man gets, the farther he had to walk to school as a boy.
4566
days inactive
4593
days old
23 comments
10 participants
participants (10)
-
Dominik 'Rathann' Mierzejewski -
Garrett Holmstrom -
Gregor Tätzner -
Jesse Keating -
Kevin Fenzi -
Richard W.M. Jones -
Roberto Ragusa -
Till Maas -
Tom Callaway -
Toshio Kuratomi