{"thread":{"id":"18438","subject":"Minimum libCurl version for git","startedAt":"2009-03-20T17:59:08Z","lastAt":"2009-03-24T07:35:44Z","messageCount":8,"participants":["Mike Ralphson","Junio C Hamano","Mike Hommey","Daniel Stenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108741","messageId":"e2b179460903201059j20e37c1cr7ccfa4b42e45c9d9@mail.gmail.com","threadId":"18438","inReplyTo":null,"subject":"Minimum libCurl version for git","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-03-20T17:59:08Z","receivedAt":"2009-03-20T17:59:08Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"See $gmane/112765 for background.\n\nGit uses 31 CURL_, CURLINFO and CURLOPT symbols, two of these\n(CURLINFO_HTTP_CODE and CURLOPT_INFILE) are officially deprecated, but\nonly because they have been renamed in 'recent' versions.\n\nWe protect the usage of symbols introduced in version 7.9.2 and later\nwith #ifdefs. These date back to some time in 2005 when those versions\nof libCurl were 3 or so years old.\n\nWe use CURLOPT_FTP_USE_EPSV unprotected, which was introduced in\nversion 7.9.2. This is something of a pity as it is an optional\nconfiguration item which is probably not widely used (I don't think I\nknew there was any support for git over ftp). Still, 7.9.2 was a long\ntime ago (Dec 2001), and no-one is complaining. Disregarding this, we\nwould be able to use libCurl versions as far back as 7.8.1 (Aug 2001),\nbugs, security fixes and performance notwithstanding.\n\nAccording to Daniel's list [1], CURLOPT_SSLKEY was introduced in\n7.9.3, but we enable it in http.c if we see version >= 7.9.2. This\ncould be a typo in the haxx.se list, or the option could have been\navailable in (some) 7.9.2 releases, or it could be a git bug. Again,\nnot one which appears to be biting anyone.\n\nGoing forward there are various options:\n\n1. Do nothing - go with the status quo.\n\n2. Correct the #ifdefs for CURLOPT_SSLKEY\n\n3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our\nminimum supported version. I feel slightly embarrassed about that, as\nthat's exactly the version I have here on AIX (unless I wrest it back\nfrom being sysadmin-installed to being user-supported). Add a check to\nthe Makefile and error if libCurl is too old.\n\n4. Drop all current #ifdefs and one of the deprecated symbol names.\nOur minimum supported libCurl version would be 7.9.8 from Jun 2002.\n\n5. Drop all current #ifdefs and both of the deprecated symbol names.\nOur minimum supported libCurl version would be 7.10.8 from Nov 2003.\n\n6. Warn (not error) if libCurl is older than say the 3 years suggested\nby Daniel. This would seem to require periodic updates to the Makefile\ncheck.\n\nI'm happy to whip up a patch if required, but I thought a series of\nmutually-exclusive alternative patches would be confusing without\nprior agreement on the approach.\n\nMike\n\n[1]  http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup\n"},{"id":"108762","messageId":"7vy6uzg98v.fsf@gitster.siamese.dyndns.org","threadId":"18438","inReplyTo":"e2b179460903201059j20e37c1cr7ccfa4b42e45c9d9@mail.gmail.com","subject":"Re: Minimum libCurl version for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-20T21:44:16Z","receivedAt":"2009-03-20T21:44:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Ralphson writes:\n\n> Going forward there are various options:\n>\n> 1. Do nothing - go with the status quo.\n>\n> 2. Correct the #ifdefs for CURLOPT_SSLKEY\n>\n> 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our\n> minimum supported version. I feel slightly embarrassed about that, as\n> that's exactly the version I have here on AIX (unless I wrest it back\n> from being sysadmin-installed to being user-supported). Add a check to\n> the Makefile and error if libCurl is too old.\n>\n> 4. Drop all current #ifdefs and one of the deprecated symbol names.\n> Our minimum supported libCurl version would be 7.9.8 from Jun 2002.\n>\n> 5. Drop all current #ifdefs and both of the deprecated symbol names.\n> Our minimum supported libCurl version would be 7.10.8 from Nov 2003.\n>\n> 6. Warn (not error) if libCurl is older than say the 3 years suggested\n> by Daniel. This would seem to require periodic updates to the Makefile\n> check.\n>\n> I'm happy to whip up a patch if required, but I thought a series of\n> mutually-exclusive alternative patches would be confusing without\n> prior agreement on the approach.\n>\n> Mike\n>\n> [1]  http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup\n\nThanks for a detailed analysis.\n\nMy gut feeling is we should be able to do 3 safely.\n\nI am not sure if you are reading the \"deprecated\" column correctly,\nthough:\n\n Name Introduced Deprecated Removed\nCURLINFO_HTTP_CODE 7.4.1 7.10.8\nCURLOPT_INFILE 7.1 7.9.7\n\nThese two symbols are what we do use in our code, so the\ndeprecated/removed column would give us the upper bound of the versions,\nnot the lower bound.\n\nWe can have these two macro definitions on our side\n\n\t#if curl older than 7.10.8\n #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE\n\t#endif\n\n\t#if curl older than 7.9.7\n #define CURLOPT_READDATA CURLOPT_INFILE\n\t#endif\n\nfor backward compatibility, while writing our code to the recent API by\nusing CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older\ncurl would not have to suffer a bit.\n\nSo I think your 4 and 5 are non issues.\n\nBut this is without having a handy tally of what releases of various\ndistros shipped their libcurl with. If we had a table like this...\n\nDistro\t\t\tLast update\t\tlibcurl version\n----------------------------------------------------------------\nDebian 3.1 sarge\t2005-06-06\t\t???\nDebian 4.0 etch\t\t2009-02-10 (4.0r7)\t7.15.5\nDebian 5.0 lenny\t2009-02-14\t\t7.18.2\n\n... then we could say \"This is git, a tool primarily for developers to\nkeep track of sources; nobody would be running on a box that was updated\nthe last time four years ago, so we can safely assume libcurl more recent\nthan version ???\".\n\nIt would also be valid to argue that \"4.0 etch may have been updated last\nmonth, but libcurl 7.15.5 has been available on the release a lot before\nthat, as of 200X-XX-XX, which is more than N years ago, which makes it\nsafe to assume that assuming 7.15.5 or later is fine for Debian folks; do\nnot get fooled by the date of last update,\" in which case it would be good\nto have entry for the original release date.\n\nFor non-commercial Linux folks I think it should be Ok to assume not too\nancient libcurl, but I have no clue on how the table like the above would\nlook like for things like AIX, IRIX, HPUX etc. ... Oh, and SCO.\n"},{"id":"108765","messageId":"20090320221358.GA24390@glandium.org","threadId":"18438","inReplyTo":"7vy6uzg98v.fsf@gitster.siamese.dyndns.org","subject":"Re: Minimum libCurl version for git","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-03-20T22:13:58Z","receivedAt":"2009-03-20T22:13:58Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Mar 20, 2009 at 02:44:16PM -0700, Junio C Hamano wrote:\n> Mike Ralphson writes:\n> \n> > Going forward there are various options:\n> >\n> > 1. Do nothing - go with the status quo.\n> >\n> > 2. Correct the #ifdefs for CURLOPT_SSLKEY\n> >\n> > 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our\n> > minimum supported version. I feel slightly embarrassed about that, as\n> > that's exactly the version I have here on AIX (unless I wrest it back\n> > from being sysadmin-installed to being user-supported). Add a check to\n> > the Makefile and error if libCurl is too old.\n> >\n> > 4. Drop all current #ifdefs and one of the deprecated symbol names.\n> > Our minimum supported libCurl version would be 7.9.8 from Jun 2002.\n> >\n> > 5. Drop all current #ifdefs and both of the deprecated symbol names.\n> > Our minimum supported libCurl version would be 7.10.8 from Nov 2003.\n> >\n> > 6. Warn (not error) if libCurl is older than say the 3 years suggested\n> > by Daniel. This would seem to require periodic updates to the Makefile\n> > check.\n> >\n> > I'm happy to whip up a patch if required, but I thought a series of\n> > mutually-exclusive alternative patches would be confusing without\n> > prior agreement on the approach.\n> >\n> > Mike\n> >\n> > [1]  http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup\n> \n> Thanks for a detailed analysis.\n> \n> My gut feeling is we should be able to do 3 safely.\n> \n> I am not sure if you are reading the \"deprecated\" column correctly,\n> though:\n> \n> Name Introduced Deprecated Removed\n> CURLINFO_HTTP_CODE 7.4.1 7.10.8\n> CURLOPT_INFILE 7.1 7.9.7\n> \n> These two symbols are what we do use in our code, so the\n> deprecated/removed column would give us the upper bound of the versions,\n> not the lower bound.\n> \n> We can have these two macro definitions on our side\n> \n> \t#if curl older than 7.10.8\n> #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE\n> \t#endif\n> \n> \t#if curl older than 7.9.7\n> #define CURLOPT_READDATA CURLOPT_INFILE\n> \t#endif\n> \n> for backward compatibility, while writing our code to the recent API by\n> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older\n> curl would not have to suffer a bit.\n> \n> So I think your 4 and 5 are non issues.\n> \n> But this is without having a handy tally of what releases of various\n> distros shipped their libcurl with. If we had a table like this...\n> \n> Distro\t\t\tLast update\t\tlibcurl version\n> ----------------------------------------------------------------\n> Debian 3.1 sarge\t2005-06-06\t\t???\n> Debian 4.0 etch\t\t2009-02-10 (4.0r7)\t7.15.5\n> Debian 5.0 lenny\t2009-02-14\t\t7.18.2\n> \n> ... then we could say \"This is git, a tool primarily for developers to\n> keep track of sources; nobody would be running on a box that was updated\n> the last time four years ago, so we can safely assume libcurl more recent\n> than version ???\".\n> \n> It would also be valid to argue that \"4.0 etch may have been updated last\n> month, but libcurl 7.15.5 has been available on the release a lot before\n> that, as of 200X-XX-XX, which is more than N years ago, which makes it\n> safe to assume that assuming 7.15.5 or later is fine for Debian folks; do\n> not get fooled by the date of last update,\" in which case it would be good\n> to have entry for the original release date.\n\nOriginal release date for etch is 2007-04-08.\nSarge was released with libcurl 7.13.2.\nWoody, which was Debian 3.0, and can be considered dead already, was\nreleased on 2002-07-19 with libcurl 7.9.5.\n\nMike\n"},{"id":"108766","messageId":"alpine.DEB.1.10.0903202308400.2600@yvahk2.pbagnpgbe.fr","threadId":"18438","inReplyTo":"e2b179460903201059j20e37c1cr7ccfa4b42e45c9d9@mail.gmail.com","subject":"Re: Minimum libCurl version for git","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2009-03-20T22:15:12Z","receivedAt":"2009-03-20T22:15:12Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Fri, 20 Mar 2009, Mike Ralphson wrote:\n\n> According to Daniel's list [1], CURLOPT_SSLKEY was introduced in 7.9.3, but \n> we enable it in http.c if we see version >= 7.9.2. This could be a typo in \n> the haxx.se list, or the option could have been available in (some) 7.9.2 \n> releases, or it could be a git bug. Again, not one which appears to be \n> biting anyone.\n\nI double-checked now against the changelog and it confirms that the info is \ncorrect in that file: CURLOPT_SSLKEY was introduced in 7.9.3. It was first \nreleased in a pre-release Jan 8th 2002.\n\nI'd assume that very few git-builders have such an old libcurl installed...\n\n-- \n\n / daniel.haxx.se\n"},{"id":"108769","messageId":"alpine.DEB.1.10.0903202316170.2600@yvahk2.pbagnpgbe.fr","threadId":"18438","inReplyTo":"7vy6uzg98v.fsf@gitster.siamese.dyndns.org","subject":"Re: Minimum libCurl version for git","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2009-03-20T22:31:30Z","receivedAt":"2009-03-20T22:31:30Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Fri, 20 Mar 2009, Junio C Hamano wrote:\n\n> For non-commercial Linux folks I think it should be Ok to assume not too \n> ancient libcurl, but I have no clue on how the table like the above would \n> look like for things like AIX, IRIX, HPUX etc. ... Oh, and SCO.\n\nThe oldest libcurl version I know is still being distributed to and therefor \nused by people is one IBM provides for AIX, and that is 7.9.3 - dated \"Jan 23 \n2002\".\n\n-- \n\n / daniel.haxx.se\n"},{"id":"108770","messageId":"7vtz5ng5t2.fsf@gitster.siamese.dyndns.org","threadId":"18438","inReplyTo":"alpine.DEB.1.10.0903202316170.2600@yvahk2.pbagnpgbe.fr","subject":"Re: Minimum libCurl version for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-20T22:58:33Z","receivedAt":"2009-03-20T22:58:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Stenberg writes:\n\n> On Fri, 20 Mar 2009, Junio C Hamano wrote:\n>\n>> For non-commercial Linux folks I think it should be Ok to assume not\n>> too ancient libcurl, but I have no clue on how the table like the\n>> above would look like for things like AIX, IRIX, HPUX etc. ... Oh,\n>> and SCO.\n>\n> The oldest libcurl version I know is still being distributed to and\n> therefor used by people is one IBM provides for AIX, and that is 7.9.3\n> - dated \"Jan 23 2002\".\n\nThanks for the definitive words, Daniel.\n\nMike, I'd say we declare 7.9.3 as the floor and go from there. That's\nyour #3, I think.\n"},{"id":"109048","messageId":"e2b179460903230424v1c98d73ci1f41918807fb2d5c@mail.gmail.com","threadId":"18438","inReplyTo":"7vy6uzg98v.fsf@gitster.siamese.dyndns.org","subject":"Re: Minimum libCurl version for git","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-03-23T11:24:57Z","receivedAt":"2009-03-23T11:24:57Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/3/20 Junio C Hamano :\n> We can have these two macro definitions on our side\n>\n>        #if curl older than 7.10.8\n>        #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE\n>        #endif\n>\n>        #if curl older than 7.9.7\n>        #define CURLOPT_READDATA CURLOPT_INFILE\n>        #endif\n>\n> for backward compatibility, while writing our code to the recent API by\n> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older\n> curl would not have to suffer a bit.\n\nSee? That's why they pay you the big maintainer-bucks... 8-)\n\n> Mike, I'd say we declare 7.9.3 as the floor and go from there. That's\n> your #3, I think.\n\nShort patch series to follow, though maybe not today.\n\nMike\n"},{"id":"109161","messageId":"7vvdpz2x0v.fsf@gitster.siamese.dyndns.org","threadId":"18438","inReplyTo":"e2b179460903230424v1c98d73ci1f41918807fb2d5c@mail.gmail.com","subject":"Re: Minimum libCurl version for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-24T07:35:44Z","receivedAt":"2009-03-24T07:35:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Ralphson writes:\n\n> 2009/3/20 Junio C Hamano :\n>> We can have these two macro definitions on our side\n>>\n>>        #if curl older than 7.10.8\n>>        #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE\n>>        #endif\n>>\n>>        #if curl older than 7.9.7\n>>        #define CURLOPT_READDATA CURLOPT_INFILE\n>>        #endif\n>>\n>> for backward compatibility, while writing our code to the recent API by\n>> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older\n>> curl would not have to suffer a bit.\n>\n> See? That's why they pay you the big maintainer-bucks... 8-)\n\nThe big maintainer-buck is called zero cents. I am only paid with the\nfreedom to spend 20% of my day-job time on git [*1*].\n\nIn any case, \"Write to the latest API, support older platforms with\nbackward compatibility wrapper as necessary\" is a good practice employed\nby many successful projects, including the kernel, and I think it would\napply here nicely.\n\n>> Mike, I'd say we declare 7.9.3 as the floor and go from there. That's\n>> your #3, I think.\n>\n> Short patch series to follow, though maybe not today.\n\nThanks.\n\n[Footnote]\n\n*1* ... which is still generous of my employer and NEC, given the current\neconomic climate, but I wouldn't exactly call that \"big bucks\" ;-).\n"}]}