Re: unison and protocol breakage
On Feb 17, 2008, at 19:28, Vincent Lefevre wrote: On 2008-02-17 09:15:47 -0500, Kevin Ballard wrote: Right now we're providing the official, released, stable version. That's what we should provide. I agree that it should be provided. What I was requesting is that 2.13 be provided as well (but 2.27 would still be the default). And I don't think one can blame Debian or administrators of machines that have 2.13 only, in particular because 2.27 was released as stable on January 21: http://tech.groups.yahoo.com/group/unison-announce/message/51 i.e. less than a month ago. If you still think that 2.13 is outdated and must not be provided for this reason, then I propose to remove any software that is more than one-month old. Vincent, I'm sure you were proposing that to illustrate how ludicrous it would be. I'm sure we currently have many many ports that install software that's outdated by more than a month. On Feb 17, 2008, at 07:36, Kevin Ballard wrote: No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. Kevin, I think we are in fact in the business of providing old port versions too. Where the newer version of the software is incompatible in some way with the older version of the software, it's reasonable to have two portfiles, if there is still demand for the older version. We already have this for several software packages. Consider php5 and php4; apache2, apache20 and apache; apr and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, db42, db41 and db3. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
On Feb 18, 2008, at 4:34 AM, Ryan Schmidt wrote: On Feb 17, 2008, at 07:36, Kevin Ballard wrote: No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. Kevin, I think we are in fact in the business of providing old port versions too. Where the newer version of the software is incompatible in some way with the older version of the software, it's reasonable to have two portfiles, if there is still demand for the older version. We already have this for several software packages. Consider php5 and php4; apache2, apache20 and apache; apr and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, db42, db41 and db3. That's a bit different - those are specific versions as required by other ports (at least, if they aren't then why the hell do we still have Portfiles for them?). Unison is not required by other ports, and if it were these other ports wouldn't require a specific version. Therefore, we shouldn't be providing old ports because we don't have to maintain them for dependencies. If the majority of committers want to say lets provide unison 2.13, I will disagree, but I will not stop you. Note: It really is fairly trivial to install unison by hand once you have OCaml installed. If you have a debian machine that doesn't provide unison 2.27, just install it manually! Seriously! It's easier than trying to get Unison 2.13 into MacPorts. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org [EMAIL PROTECTED] http://www.tildesoft.com ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
On Feb 18, 2008, at 07:48, Kevin Ballard wrote: On Feb 18, 2008, at 4:34 AM, Ryan Schmidt wrote: On Feb 17, 2008, at 07:36, Kevin Ballard wrote: No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. Kevin, I think we are in fact in the business of providing old port versions too. Where the newer version of the software is incompatible in some way with the older version of the software, it's reasonable to have two portfiles, if there is still demand for the older version. We already have this for several software packages. Consider php5 and php4; apache2, apache20 and apache; apr and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, db42, db41 and db3. That's a bit different - those are specific versions as required by other ports (at least, if they aren't then why the hell do we still have Portfiles for them?). Unison is not required by other ports, and if it were these other ports wouldn't require a specific version. Therefore, we shouldn't be providing old ports because we don't have to maintain them for dependencies. [snip] I wouldn't say it's only about dependencies. For example: php4 contains some functionality that was dropped or changed in php5, so some sites that work with php4 do not work with php5 without some changes. A developer of such a site might reasonably want to install php4 using MacPorts to continue developing his site. apache20 exists for the reason explained at length in the Portfile: to support the use of third-party binary modules compiled for Apache 2.0, which would not work in Apache 2.2 without recompilation. The several postgresql ports exist, as I understand it, because the database format is binary-incompatible between releases, requiring the user to perform a manual migration. It was thought that breaking a user's database just because they ran sudo port upgrade outdated was rude. So, in all these cases, we are concerned with the MacPorts user who wants to continue using the old version of the software, because the newer version works incompatibly. It doesn't matter if other ports depend on these older versions. Note: It really is fairly trivial to install unison by hand once you have OCaml installed. If you have a debian machine that doesn't provide unison 2.27, just install it manually! Seriously! It's easier than trying to get Unison 2.13 into MacPorts. I would still agree it's better to install the latest software on the other machine, rather than get the older software into MacPorts. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
On Feb 18, 2008, at 6:39 PM, Ryan Schmidt wrote: php4 contains some functionality that was dropped or changed in php5, so some sites that work with php4 do not work with php5 without some changes. A developer of such a site might reasonably want to install php4 using MacPorts to continue developing his site. both php4 and php5 are currently actively supported release versions of php, as well. The several postgresql ports exist, as I understand it, because the database format is binary-incompatible between releases, requiring the user to perform a manual migration. It was thought that breaking a user's database just because they ran sudo port upgrade outdated was rude. postgresql.org also lists 7.4.19, 8.0.15, 8.1.11, 8.2.6, and 8.3.0 under 'Latest Releases' (all are currently supported versions) Note: It really is fairly trivial to install unison by hand once you have OCaml installed. If you have a debian machine that doesn't provide unison 2.27, just install it manually! Seriously! It's easier than trying to get Unison 2.13 into MacPorts. I would still agree it's better to install the latest software on the other machine, rather than get the older software into MacPorts. True, but I don't see why we care if someone wants to be responsible for maintaining a port for an older version for one reason or another (we can always remove it if/when it becomes unmaintained). -- Daniel J. Luke ++ | * [EMAIL PROTECTED] * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. If you're using debian/stable, just install unison 2.27 yourself. IIRC the default location is $HOME/bin, so you don't need to do *any* work to install it besides download the source and build it. Presumably you have ocaml installed already. -Kevin Ballard On Feb 16, 2008, at 8:18 PM, Vincent Lefevre wrote: The unison port has recently been upgraded from 2.13 to 2.27. The problem is that the protocol has changed between these versions, and unison 2.13 can't talk to unison 2.27: http://trac.macosforge.org/projects/macports/ticket/14172 The only solution that can work in every case (because users may need to do synchronization with machines that only have 2.13 and machines that only have 2.27) is to install the two binaries: unison-2.13 and unison-2.27 (note: when executing the remote unison binary, unison can automatically add its main version number thanks to the addversionno option). So, I think that the best solution is to have a port for the old version unison 2.13 (BTW, this is what Debian does for the 2.9 version and will probably do for the 2.13 version), which installs only the unison-2.13 binary (alternatively, there could be a variant that installs a unison binary too for those who don't need unison 2.27). In this case, what should the name of the port be? unison-2.13? unison2.13? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/ blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- Lyon) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- Kevin Ballard http://kevin.sb.org [EMAIL PROTECTED] http://www.tildesoft.com ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
Right now we're providing the official, released, stable version. That's what we should provide. -Kevin Ballard On Feb 17, 2008, at 9:08 AM, Paul Guyot wrote: I'd say the good strategy is to have the ubiquitous version. At some point I synchronized the version of unison with the version available with FreeBSD ports because it's what I used on the other end. On the other hand, debian/stable is lagging so much that they probably should not be considered as a reference. Paul Le 17 févr. 08 à 14:36, Kevin Ballard a écrit : No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. If you're using debian/stable, just install unison 2.27 yourself. IIRC the default location is $HOME/bin, so you don't need to do *any* work to install it besides download the source and build it. Presumably you have ocaml installed already. -Kevin Ballard On Feb 16, 2008, at 8:18 PM, Vincent Lefevre wrote: The unison port has recently been upgraded from 2.13 to 2.27. The problem is that the protocol has changed between these versions, and unison 2.13 can't talk to unison 2.27: http://trac.macosforge.org/projects/macports/ticket/14172 The only solution that can work in every case (because users may need to do synchronization with machines that only have 2.13 and machines that only have 2.27) is to install the two binaries: unison-2.13 and unison-2.27 (note: when executing the remote unison binary, unison can automatically add its main version number thanks to the addversionno option). So, I think that the best solution is to have a port for the old version unison 2.13 (BTW, this is what Debian does for the 2.9 version and will probably do for the 2.13 version), which installs only the unison-2.13 binary (alternatively, there could be a variant that installs a unison binary too for those who don't need unison 2.27). In this case, what should the name of the port be? unison-2.13? unison2.13? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/ blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- Lyon) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- Kevin Ballard http://kevin.sb.org [EMAIL PROTECTED] http://www.tildesoft.com ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- http://paul-guyot.com/ -- Kevin Ballard http://kevin.sb.org [EMAIL PROTECTED] http://www.tildesoft.com ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
On 2008-02-17 08:36:37 -0500, Kevin Ballard wrote: No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. So, what about these old db, qt and automake ports? If you're using debian/stable, just install unison 2.27 yourself. That's too much work (too many machines). I now have my local unison-2.13 port. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: unison and protocol breakage
On 2008-02-17 09:15:47 -0500, Kevin Ballard wrote: Right now we're providing the official, released, stable version. That's what we should provide. I agree that it should be provided. What I was requesting is that 2.13 be provided as well (but 2.27 would still be the default). And I don't think one can blame Debian or administrators of machines that have 2.13 only, in particular because 2.27 was released as stable on January 21: http://tech.groups.yahoo.com/group/unison-announce/message/51 i.e. less than a month ago. If you still think that 2.13 is outdated and must not be provided for this reason, then I propose to remove any software that is more than one-month old. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
unison and protocol breakage
The unison port has recently been upgraded from 2.13 to 2.27. The problem is that the protocol has changed between these versions, and unison 2.13 can't talk to unison 2.27: http://trac.macosforge.org/projects/macports/ticket/14172 The only solution that can work in every case (because users may need to do synchronization with machines that only have 2.13 and machines that only have 2.27) is to install the two binaries: unison-2.13 and unison-2.27 (note: when executing the remote unison binary, unison can automatically add its main version number thanks to the addversionno option). So, I think that the best solution is to have a port for the old version unison 2.13 (BTW, this is what Debian does for the 2.9 version and will probably do for the 2.13 version), which installs only the unison-2.13 binary (alternatively, there could be a variant that installs a unison binary too for those who don't need unison 2.27). In this case, what should the name of the port be? unison-2.13? unison2.13? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
