Re: [Bug-readline] build failure with readline 6.3 and python, samba and parted

[Max Horn]

Hi again,

On 10.04.2014, at 17:39, Chet Ramey <address@hidden> wrote:

> Signed PGP part
> On 4/10/14, 9:11 AM, Max Horn wrote:
> > 
> > On 03.03.2014, at 20:19, Chet Ramey <address@hidden> wrote:
> > 
> >> On 3/3/14 1:04 PM, Juergen Daubert wrote:
> >>> Hello,
> >>>
> >>> after installing the new readline 6.3 I rebuild a couple of packages 
> >>> on my system (Linux, gcc 4.7.3, glibc 2.16.0) and get errors for the 
> >>> following:
> >>
> >> Yes, those old-style function typedefs have been deprecated for a couple
> >> of releases now.  I finally removed them in readline-6.3.
> > 
> > Late reply, but: This is a bit unfortunate, as it constitutes an API 
> > breakage. I just got a bug report about this because me updating the Fink 
> > readline6 package to 6.3.3 broke our python package. So now I'll have to 
> > patch the header to add back the typedef.
> 
> I understand that fink, like bash and readline, is an open-source project
> run by primarily volunteers.  However, I'm disappointed that this slipped
> through the testing releases.

Uhm, shouldn't removing something from a header always be a red flag for a 
release that's not meant to break backwards compatibility? I could say I am 
disappointed that *this* slipped through, but then I realize you are just a 
human and a volunteer yourself :-).

Anyway, I am not sure how realistic it is to expect packagers like Juergen or 
me to catch this kind of issue early. After all, readline 6.3 works fine for 
most packages. But we work on relatively small projects, and don't have the 
resources to test build hundreds or even thousands of packages to see whether 
they still work with the latest readline.

Apparently not even Ubuntu has run into the problem so far? (At least I don't 
see them adding the typedefs back in their readline package, nor do I see 
patches in their Python 2.7 package).


Anyway, from my POV it's all not that bad. Python 2.7 and 3.2 are the only 
affected packages I got failure reports about, and we (= Fink) have now fixed 
both of them, and my readline6 package also for now adds back the typedefs, in 
case there are further failures. And I don't mind doing that indefinitely if 
necessary.

So, for me resp. for Fink, the issue is resolved, and I wouldn't have to email. 
However,  I am pretty sure other distros will run into the exact same issue, 
which is why I chose to bother you anyway :-).



> 
> 
> > Thing is, while this typedef may have been deprecated for a couple of 
> > releases, there was no real means for client code to notice this, was 
> > there? 
> 
> In general, this is always the case.  This is the reason to distribute
> testing versions: so maintainers with access to other systems and packages
> can see whether or not things break in a way that requires readline to be
> changed before a final release.

Yeah, in an ideal world, that would work. Unfortunately, unlike e.g. Ubuntu, we 
don't have enough capacity to provide test building of all packages for every 
developer...

But hey, at least I follow this list. Not sure how many other readline 
packagers do that... ? ;-).



> 
> 
> I suppose other than the periodic complaints about readline `polluting' the
> application's namespace, there really is no way to keep up unless you pay
> attention to development versions.
> 
> It's a hard problem.  I recently encountered it when a change to bash, made
> three years ago, available in development git snapshots since, and
> released as part of bash-4.3, violated some of the assumptions the bash-
> completion package makes.  You'd wish that it had been discovered before
> release.
> 
> > 
> > So, perhaps they could be added back for now, but with a twist: add 
> > __attribute__((deprecated)); to them, at least for compilers that support 
> > it (gcc, clang). And also say clearly that these will be released in 
> > readline 7 (which will be free to break API and ABI, I assume).
> 
> This is an interesting approach.  I will try it and release it as a
> readline patch.

Awesome, thanks a lot.


Cheers,
Max