lsb

clarify handling of deprecated libraries

Bug #1334776 reported by Jeff Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lsb
Fix Committed
Medium
Unassigned
Mandriva
Fix Released
Medium

Bug Description

Currently deprecated libraries are included in LSB versions where they are
deprecated. This is certainly correct for the runtime environment -
specification, checkers, etc. Whether it's the correct approach for the stub
libraries in the development environment is less clear.

The question arises particularly in the case of libpng12, which needs to be
deprecated to accomodate the ABI-incompatible (at least partly) libpng15.
Since the changes are visible in the png.h header as well, LSB header version
protection means there will not be a way to build targeting LSB 5.0 and
libpng12 using the png.h header, because the version ifdefs will pick the
changes that match the libpng15 uplift. Thus it's possible the stub for this
library should be omitted from the stub libraries. As a contrast,
libgtk-x11-2.0 and libgdk-x11-2.0 will be deprecated in favor of libgtk-3, but
here the intent is to continue to be able to buiild for the old version, done
through a disjoint set of headers.

This is filed to track the question of whether there are cases where the stub
should actually be omitted, and if so how to make it work.

As an alternative, it's probably possible to force the "old" png.h header into
a distinct path (/opt/lsb/include/libpng12/png.h) and tell people they have to
use #include <libpng12/png.h> if they want to access the old way, but it's not
clear whether this is going to be "industry standard".

Tags: spec gtk3 uplift
Changed in mandriva:
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.