RPM Community Forums

Mailing List Message of <popt-devel>

Re: POPT's API has designed in memory leaks. What to do?

From: Danny Sung <danny@dannysung.com>
Date: Mon 07 Jun 2010 - 20:00:51 CEST
Message-ID: <4C0D33D3.6030805@dannysung.com>
I agree.  I have no problems with breaking binary&source compatibility 
especially if that change will make popt better/easier in the future. 
But a change in name seems necessary for app developers to make that 
choice.  eg. what happens if you're building mulitiple different 
software packages... both dynamically linking popt, but one uses 1.x and 
the other 2.x?  The header files would also need something like #include 
<popt2/popt2.h> or something like that.  Can't say I particularly like 
it... but it does those issues somewhat cleanly.

I don't think it's that bad for developers to switch over.  Old apps may 
take a while.  But people will know (especially if you put "#warning 
popt-1.x is deprecated" in the headers for 1.x. =) ).  And will move new 
software over.  Look at things like libxml2.

Ideally, however, popt2 should include mechanisms that allow for future 
versions to do this sort of versioning check at runtime.  So this popt2 
actually becomes popt ABI 2.0.  Not popt-2.0.  (eg. popt3 may still use 
popt2 ABI.. but then again with all the versioning there may never need 
to be a popt3 =) ).

On 6/7/2010 9:51 AM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson <n3npq@mac.com
> <mailto:n3npq@mac.com>> wrote:
>     The added tyrrany of forcing every application that currently has
>     -lpopt
>     to change to
>     -ljdod
>     will be rate-determining to adoption (and glacially/tectonically
>     slow imho)
> For me, if popt 2 is not compatible with popt 1 then I would rather have
> to make a conscious choice to upgrade my code (testing it for
> compatibility), and having to change the libray name as a part of that
> is pretty minor.  Having a possibility for my program to be run-time
> linked with a library that is not compatible with what it expects would
> be very bad, imo.
> ..wayne..

Please note my new email address: danny@dannysung.com
Received on Mon Jun 7 20:01:14 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.