[lsb-discuss] Qt issues: deprecating Qt 3, use of qmake, proposed database changes

Jeff Licquia jeff at licquia.org
Wed Nov 21 11:28:58 PST 2007


On today's conference call, some issues with the Qt work came up.  After 
some discussion, it became clear that they wouldn't get resolved on the 
call, and should be brought up on the list for comment.

Qt 3 deprecation
----------------

The first issue concerns Qt 3 deprecation.  The question is whether we 
should issue a deprecation warning in LSB 3.2, which would start the 
deprecation clock ticking.

On the pro side, we don't know how long distributions will want to keep 
Qt 3 around.  There's the possibility that it will be more popular than 
Qt 2, because many more commercial Linux apps used Qt 3 than Qt 2.  And 
deprecation does not mean that we must remove things on a certain 
timetable--only that we may.  So, we can always keep it around as long 
as we need.  Finally, it seems that Qt 3 is already considered 
end-of-life by TrollTech; see http://trolltech.com/products/qt/qt3.

For reference, Qt 3 was released in October of 2001, and seems to have 
completely disappeared from all distros long before now, six years 
later.  With our current three-version (approximately six-year) 
deprecation policy, this may put an undue burden on distros.

On the con side, it may be a lot of work; we've never deprecated a whole 
module before.  We're only talking about a year or so of delay, as we 
would take up the issue as part of LSB 4.0 if we didn't do it now.  And 
it's clear that Qt 3 is still very much in use; we don't even have a 
formal release of KDE which uses Qt 4 yet.

So, we should decide whether to deprecate yet or not for 3.2.

Use of qmake
------------

The Qt 3 deprecation issue came up because of our use of qmake.  In LSB 
3.1, qmake decides which version of Qt to use by looking at whether 
optional modules are enabled; if so, Qt 4 is used.  That won't work in 
LSB 3.2, because both Qt 3 and 4 are required.

The proposal is that, by deprecating Qt 3, we can make Qt 4 the default, 
with Qt 3 support being enabled via an environment variable.

However, we could also do this without deprecating Qt 3.

The issue is filed as bug 1783.

Database changes
----------------

The ISPRAS/TrollTech work to uplift Qt 4 in the database has progressed 
well, but has evidently introduced some discrepancies between the spec 
and most implementations.

This is being tracked as bug 1780.  It seems progress is being made, but 
interested parties might want to follow progress on that bug.



More information about the lsb-discuss mailing list