On Jun 20, 2010, at 9:14 AM, Wichmann, Mats D wrote:
>>
>> I can/will chase down a "straw-man" implementation using loader maps
>> and versioned symbols for "compatibility" over the next month
>> because I _REALLY_ think renaming to "popt2" is just wussiness.
>
> fwiw, I've found more than one instance of projects getting symbol
> versioning religion, just adding it, and creating considerable confusion.
> if libfoo 1.14 is unversioned and 1.15 suddenly is versioned then you
> may get surprises. it's not an utter disaster to do both: bump to
> 2.0 and use all the versioning tricks from there.
>
POPT added symbol versioning using loader maps years ago.
No confusion has been reported (although I'm quite sure that distros
are not enabling symbol versioning)
If distros don't enable the mechanism to support symbol versioning that
might permit both POPT 1.0 and POPT 2.0 interfaces in
a single library, that's no problem a developer can solve.
I don't mind bumping the soname (although that too voids all attempts
at "compatibility" using symbol versioning). I personally don;y
think "compatibility" is all that important. There's zillions of
versions of popt around, all "work", and I don't expect too much interest
in using POPT 2.0, judging from comments (and the number of members
on this list).
I _DO_ mind renaming the entire project to "popt2" and adding -lpopt2 for
the sole semiotic purpose of messaging to lusers:
Danger Will Robinson! Toriodal turbulence in the API/ABI is detected!
> disclaimer: I haven't looked at what issues you may be facing,
> going to 2.0 may indeed be as you characterize it :)
Largely I'm just collecting "features" desired in POPT 2.0.
As always, the only "feature" that everyone wants is "No incompatibilities!"
Which is trivially solved by doing nothing, which is still an alternative
development choice for POPT.
Thanks for comments.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
