On Jun 7, 2010, at 4:40 PM, Danny Sung wrote:

> On 6/7/2010 11:29 AM, Jeff Johnson wrote:
>> On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
>>> 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 respectfully and strongly _DISAGREE_. The issue can be best be
>> dealt with by using ELF symbol versioning (once I get that it place
>> again in popt-1.17) where a single library can provide _BOTH_
>> POPT 1.0 and POPT 2.0 functionality _TRANSPARENTLY_ (one the
>> necessary pre-requsite of adding ELF symbol versioning is achieved).
> Doesn't this only work if you're maintaining source compatibility? (whiihc is 
> good, I just thought you said you weren't aiming for that).
> Sorry, not trying to be difficult... just trying to understand.  Also does 
> ELF symbol versioning work for both dynamically and statically linked apps?

ELF symbol versioning is what glibc uses to have a forward looking
upgrade path. If it "works" for glibc, that's all I (and perhaps you) need to 

I do know more about ELF symbol versioning, its not very hard, if interested.
Its largely a conscious design choice releasing a library, the rest is
just "stuff".

>> If I rename "popt" to "tdod" (or "popt2" that precludes even the attempt at
>> doing better engineering using ELF symbol versioning. While I'm
>> not averse to renaming, I've seen the bleary package churn from
>> libxml ->  libxml2 and GNOME 1.0 ->  GNOME 2.0. No way Jose!
> Yeah, I thought it was ugly too.  But it makes sense... in an ugly way.

We agree "pugly". FWIW, months of my life has been spent staring
at splint traces. If you think the code is ugly, wait until you see
10K lines of spewage (and attempt to "fix").

These days scan.coverity.com is better technology than splint (and
POPT is already a registered project with scan.coverity.com, I signed
up almost instantly when scan.coverity.com was announced).

However, scan.coverity.com takes quite some time (months and years)
to scan a new release, and is an exorbitanly prohibitively expensive
proprietary tool for FLOSS development.

Note that scan.coverity.com still thinks that rpm-2.5.x released
in August, 1998 is still "current" software that is usefully scanned
(because rpm-2.5.x is _STILL_ in NetBSD 12 years later). MHO differs
considerably, I have no need to examine "bugs" in 12 year old releases
for any purpose whatsoever. But I digress ...

Which makes splint attractive for POPT development even if the annotations
are quite pugly and intrusive.


73 de Jeff
> ______________________________________________________________________
> POPT Library                                           http://rpm5.org
> Developer Communication List                       popt-devel@rpm5.org

POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to