[lsb-discuss] qt3: testing our deprecation strategy
Anthony W. Youngman
wol at thewolery.demon.co.uk
Tue Aug 11 08:45:10 PDT 2009
In message <4A76E572020000E000054E89 at sinclair.provo.novell.com>, Kay
Tate <ktate at novell.com> writes
> > On Wed, Jul 29, 2009 at 08:48:03AM +0100, Anthony W. Youngman wrote:
>> For symbols that which were deprecated in LSB 3.2 or earlier but
>> not yet withdrawn as of LSB 4.0, if there are no certified
>> applications that have used the interface/library, it may be
>> removed in LSB 4.1 without any further warnings. If, however, the
>> interface/library has been used in one or more certified
>> applications, the LSB workgroup may decide to withdraw the
>> interface at the next LSB release after 3 years instead of 5
>> years, with an appropriate warning issued by the LSB application
>At the present time, since there are so few certified applications, we
>should take the Navigator data into consideration, not just the
>certified applications. If, in the Navigator, significant commercial
>applications or significant numbers of smaller applications use an
>interface/library, we should not remove the it without warning. We want
>to encourage them to certify. When we determine that we have critical
>mass for certified applications, we can use the above language.
> -Kay T.
Responding late (I know, but I was on holiday and didn't have access to
my usual facilities...)
Do I remember correctly that certified applications have paid or
whatever it is for commercial certification, while "compliant"
applications have passed the test suite but not been officially signed
As another strawman :-) going back to my original proposal, what about
adding a third state? While we want certified applications, we should
still just drop interfaces and not deprecate them, their presence is
guaranteed by the compatibility with earlier versions. So we have
certified apps that only use the LSB interfaces in the version they
claim certification to. We have compliant apps where the vendor claims
they will work on a certain version of LSB (and are allowed to depend on
interfaces in earlier versions), and we have "certified compliant" apps
which are certified to work on that LSB version, but which are not
"pure" to that version because they contain a requirement for interfaces
in a previous LSB.
That way, *users* know that any app certified to LSB 4 (for example)
will work on any system certified to any newer LSB that requires
backwards compatibility with 4. They also know that any app "certified
compliant" to 4 will work on 4, but might not work on a newer version
due to its reliance on deprecated components, even if the newer version
pulls in 4 as a dependency.
I'm trying to get my head round a possible problem with Ted's example,
which others may be able to solve. Let's say my app requires Qt 3 and
dirfd as Ted suggests. I get it certified to v4. Then v5 comes out and
Qt3 is dropped. My distro claims v5 compliance but doesn't include Qt3
... so I assume my certified v4 app will run and it bombs ...
Basically, what I'm trying to say is if you allow an app to certify to
the new standard, but also allow it to depend on deprecated interfaces,
are you going to get a nasty chain of dependencies that says LSB5 is
supposed to guarantee any LSB4 apps will run, but those apps are allowed
to depend on LSB3 interfaces so LSB5 has to support all the LSB3
interfaces. Will this chain get out of hand?
What I'm trying to draw for certified apps is a distinction between apps
that "only use interfaces in the certified LSB version", and ones that
"use interfaces that are guaranteed to be available in a certified
version (ie deprecated ones)".
So basically, we need some certification method that says "this app will
run on any v4 compatible distro" or that "this app will run on a v4
certified distro", because those two statements are NOT the same.
Anthony W. Youngman - anthony at thewolery.demon.co.uk
More information about the lsb-discuss