[lsb-discuss] qt3: testing our deprecation strategy

[Anthony W. Youngman]

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
>>    checker.
>
>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 
off?

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.

Cheers,
Wol
-- 
Anthony W. Youngman - anthony at thewolery.demon.co.uk