On dom, ott 28, 2012 at 02:09:33 -0400, Dave Reisner wrote:
> On Sun, Oct 28, 2012 at 07:01:48PM +0100, Alessandro Ghedini wrote:
> > On dom, ott 28, 2012 at 06:11:37 +0100, Daniel Stenberg wrote:
> > > On Sat, 27 Oct 2012, Alessandro Ghedini wrote:
> > >
> > > >>See my attached patch that does exactly this. As this *will*
> > > >>cause one or two legitimate users get an error I'm very
> > > >>interested in further feedback.
> > > >
> > > >Could this be preceded by a graceful transition period, in which
> > > >e.g. libcurl prints a big warning?
> > >
> > > libcurl can't print any effective warnings. It can show warnings in
> > > debug output and it can return errors. I don't see how adding a
> > > warning in the debug output will make _any_ user change behavior.
> > > These users are already basically doing bad copy and paste
> > > programming and I don't think they would notice such a thing.
> >
> > Yes, I meant debug mode, and thinking about this, it wasn't really a good idea.
> >
> > > But the point of this change would larger be to CAUSE the problems
> > > on purpose since hardly any of the users would actually like this
> > > option to be used in production code.
> > >
> > > The idea is to treat 1 for this option to be a bug and we now fix that bug.
> >
> > The problem, from my "Debian maintainer of curl" point of view, is that I cannot
> > upload a new curl version knowing that it will break something hoping that
> > someone, some day will notice the breakage. I have to make sure that the packages
> > affected by this change still work (or have them fixed, or at least notify the
> > respective maintainers) and this requires time.
> >
> > Now, I could just not upload the new curl version for days/weeks/months until
> > I finish this work which is fine, but it will make Debian's curl version to be
> > outdated for a while and I'd like to avoid this. The configure flag would allow
> > me to upload new curl versions with this change disabled, and at the same time
> > do all the testing needed with a curl with the change enabled.
> >
> > To make this clear, the change can and should be enabled by default, I just
> > would like a way to disable it temporarily on Debian.
>
> As Arch Linux's maintainer of curl, here's my advice:
>
> If you want it disabled, it seems to me to be a no brainer -- revert the
> patch that enables it. I don't think this should be an on/off switch
> that curl upstream provides. If you're concerned at a _distro_ level
> that things will break, then I suggest taking action at the _distro_
> level.

This easily becomes an hell if later the code touched by the reverted patch is
changed again, given that the patch proposed by Danilel spans many places.

This would also make me the maintainer of such patch set which is really something
I would like to avoid, since the chance of messing things up is not low, and
I'll gladly leave the task to someone who knows the codebase better than me.

Let's keep this as plan B :)

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html