[lsb-discuss] Qt 4 decision

Robert Schweikert robert.schweikert at mathworks.com
Thu Sep 6 05:13:56 PDT 2007



Olaf Schmidt wrote:
> [ Robert Schweikert, Mi., 5. Sep. 2007 ]
>   
>> My main concern is that we re-create "the RHEL 3 problem". Once we push
>> Qt4 to mandatory and obsolete the current version we will cut RHEL 4 as
>> a target for ISVs that must certify to LSB 3.2 due to other reasons.
>>     
>
> Of course the exact same argument can be applied to all changes in LSB 3.2. It 
> will always be possible to find a distribution version that we cut off by 
> making a change.
>   
Not necessarily. The issue really only arises when we make changes to 
major components such as Qt, GTK, libc, etc. When making changes to LSB 
by adding individual interfaces the problem generally does not occur as 
older distributions generally supply the interfaces.
> ISVs will still be able to state "RHEL>=3 or LSB>=3.2" as requirements, so I 
> do not see this as a big issue.
>   
It is a big issue. If I depend on Qt4 and do not ship the libraries the 
app will not run on RHEL 4.
>   
>> I realize we need to move forward in some way, but think we should take 
>> this opportunity to define a set of rules we can fall back on when we 
>> come to this or similar juncture again in the future.
>>     
>
> The set of rules we agreed on last year is that we release future ABI in 
> non-mandatory modules, so that ISVs and distributions know in advance where 
> we are heading. For example, by publishing Qt4 as a non-mandatory "future 
> ABI" module, we declared Qt4 to be safe to use by ISVs targeting future 
> versions of the LSB. We would show ourselves as unreliable and untrustworthy 
> if we suddenly decided to abandon this published roadmap.
>   
AFAIK we have no guidelines as to how long a given module would be 
optional, maybe something we need to address. Meaning Qt 4 could be 
optional for 3.2 just as it was previously without the LSB being 
unreliable.

Jeff,

Maybe we should devote next weeks call to try and hash out a policy 
proposal on how to deal with changes like these. We might also discuss 
whether or not we should put a time limit on optional modules. We could 
say for example:

Any optional module may be optional for a maximum of 2 releases, at 
which point it may be included in the LSB or will be dropped as a candidate.

Robert
> Olaf
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
>   

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042






More information about the lsb-discuss mailing list