Hmmm, this is not a nice situation indeed.
Politely spoken ;-)
It is probably best if
new Twinkle RPM's declare a dependency on the latest libraries.
This way one is force to upgrade to the newest library and the
problem is solved.
Well, this would help to avoid "new" twinkle crashing ungracefully on
a "pre-1.5.3" OS - but just this and nothing more. The main problem however
is "old" apps inevitably crashing on all future "new" OS, as well as
generally cling to LSB and avoiding a "new OS epoch" because "nothing will
ever be the same again".
To me the better way seems to link "new" twinkles against a "new version"
https://bugzilla.novell.com/show_bug.cgi?id=343847#c2
--- Comment #2 from joerg reisenweber 2007-11-23 19:36:20 MST ---
from http://tech.groups.yahoo.com/group/twinklephone/message/2023
Am Fr 23. November 2007 schrieb Michel de Boer:
libccgnu2-1.5.so.1 (note the .1) soname symlink created "by hand" (or by
installing the later mentioned dummy) on the build system and pointing for
now to so.0.0.7 (manually create linkername symlink libccgnu2-1.5.so.1 ->
libccgnu2-1.5.so for building purposes).
This approach needs no change at all in twinkle's sources & jobs in the first
instance, serves for the same purpose by creating a dependency, restores LSB
conformity and puts pressure on the maintainers (and thus developers) to
implement a more straightforward correct LSB conform lib scheme for comoncpp.
Once the whole mess out in the wild will hopefully be fixed the way it should
(by releasing a so.0.0.8 backport old ABI, and a so.1 "new" one), there will
be no new break in twinkle's src & binary compatibility.
In the end this means: twinkle's RPM automatically would require by dependency
a libccgnu2-1.5.so.1, which can be provided as a dummy with no binary at
twinklephone.com. This empty dummy's post-install job - for now - had the
sole task to check for and create that symlink on behalf of the distro
maintainer's commoncpp2 installation. This won't hinder a correct "new
format" official libccgnu2-1-5.so.1.0.1 rpm to obsolete this dummy with a
newer revision and to create/change this symlink, once the commoncpp2 package
is fixed (*3).
This way we could have
libccgnu2-1.5.so.0.0.3 -(ln -s)-> libccgnu2-1.5.so.1 (*1)and
libccgnu2-1.5.so.0.0.2 -(ln -s)-> libccgnu2-1.5.so.0 (*2)
live happily on same box, so old twinkles might be started for e.g regression
tests etc.
*1) created by twinklephone.com dummy-commoncpp2-1.6.0-post-install
*2) created by developer on need with installing an old commoncpp rpm
(carefully check what ldconfig is doing to this and *1)! )
*3) we hopefully end up in the future with the real commoncpp provides
/usr/lib/libccgnu2-1.5.so.1.0.1 and ldconfig creates
libccgnu2-1.5.so.1.0.1 -(ln -s)-> libccgnu2-1.5.so.1
--- snip ---
Of course this will break all new apps already linked against "new format"
commoncpp version so.0 (=10.3), but for the time of now this seems to be
twinkle and bayonne, nothing more. So an update (or better "backdate") for
comoncpp AND these 2 apps at the same moment seems not so hard
jOERG
ps: to the maintainers: please set priority of this bug to a high level,
because situation might get worse and more difficult to handle, when other
developers might decide to use the faulty ABI, and also when current binaries
linked against so.0 spread further in the "real world".
This also is reason for "blocker", because development should NOT use this
hopefully shortlive version(name), otherwise they risk to break their app with
fix of the issue.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.