FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-27-2011, 03:13 PM
Gregor Tštzner
 
Default unison formal review

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-27-2011, 05:46 PM
"Richard W.M. Jones"
 
Default unison formal review

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-27-2011, 07:27 PM
Gregor Tštzner
 
Default unison formal review

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 ...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 06:55 AM
Roberto Ragusa
 
Default unison formal review

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 09:15 AM
"Richard W.M. Jones"
 
Default unison formal review

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/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 02:20 PM
Kevin Fenzi
 
Default unison formal review

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 04:10 PM
Tom Callaway
 
Default unison formal review

-----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/

iEYEARECAAYFAk6DRvAACgkQPF6ZrZMFQmBHgACfYxNnc6My8H NOKZSKZ6WzxwfE
AHwAn0Fd87cZSkalgDkejkdEaj+FCfr5
=3fNF
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 09:00 PM
"Richard W.M. Jones"
 
Default unison formal review

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 09:15 PM
Kevin Fenzi
 
Default unison formal review

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


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-28-2011, 09:54 PM
Toshio Kuratomi
 
Default unison formal review

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org