On 27/09/2011, at 6:34 PM, Thiago Macieira wrote: > On Tuesday, 27 de September de 2011 10:03:17 craig.sc...@csiro.au wrote: >> This discussion about what to make a reference platform vs documented >> platform seems to be specific to Linux (okay, maybe embedded too, but >> discussion seems to be mostly about linux at this stage). I put it to the >> list that this is precisely what the LSB is meant to address. Most of the >> work has already been done to make Qt build against LSB 4.0 (by Harald >> Fernengel and myself). Why not make LSB 4.0 the reference *and* documented >> platform for linux? Then the only question is whether or not a particular >> flavour of linux supports the LSB spec, and this is something that all the >> major linux distros generally try to do. Yes, there will be the odd need >> for a specific hack/fix to work around the occasional distribution-specific >> deficiency or bug, but I'm only aware of one such case in order to make Qt >> build against LSB 4.0. Qt5 would seem to be the perfect time to make LSB >> 4.0 a tier 1 config/platform for Qt. >> >> Currently, I maintain a smallish patch set for each Qt release to make it >> buildable with LSB (almost all the patches now are confined to webkit). I'd >> be more than happy to work with others if there was interest in making LSB >> 4.0 a tier 1 config/platform for Qt. Currently, I can only work on this as >> my current role allows, so some help would be welcome. Granted, there are >> some issues around OpenGL versions, but those are easily resolved by adding >> an additional constraint that sits on top of LSB 4.0 (and which looks to be >> getting addressed by upcoming LSB versions anyway). The only module I have >> not yet built against LSB 4.0 is DBus, since it isn't part of the LSB, but >> Thiago has already indicated in a previous response that providing the DBus >> headers to Qt should be enough since it will try to load the QtDBus module >> dynamically at run-time and still work fine if it can't be loaded. > > Hello > > I think Qt should build with the LSB, yes. But making it our reference > platform will not exactly work, as the LSB 4.0 is now several years out of > date. I can't get the details as the website seems to still be down related > to > Linux Foundation's infrastructure downtime.
Agreed, it does lag. The LSB guys are aware of this and there have been discussions about changing that so that they are much closer to the current / leading distros. > > The LSB isn't meant to innovate in the area of support. It's meant to > standardise best practice across the industry. For that reason, it's always > behind in terms of support and will usually lag one year behind the state of > the art or more. When developing for the future, we need to look at what the > state of the art of everything else will be, not what Red Hat Enterprise > Linux > and SUSE LInux Enterprise Server shipped in 2008. (And by "look at" I don't > mean "always use") > > Take for example Wayland: when will it be available in the LSB for us to > build > against? > > Anyway, what we can do is provide documentation on what we require by using > the LSB as the baseline: it's LSB 4.0 plus these libraries upgraded and these > other libraries present. > I'd very much support this approach. Making LSB 4.0 the base with a (hopefully small) list of libraries you need to update to something more recent would be a welcome change for people working on or supporting a wider range of linux distributions than simply Ubuntu. In many cases, LSB 4.0 + a few libs would probably be satisfied out of the box on recent distros, so for those who like to be more current, things should "just work" for them. For those who need to stay on older systems, at least the libs that need to be updated or provided as part of the application's packages would be clearly defined. Another benefit of taking the LSB 4.0 + some libs approach is that it sends very clear messages to the LSB guys as to what things they should consider adding to the next version of the LSB spec itself. Currently, I get the feeling that there's not a whole lot of communication going between the Qt and LSB communities, which is funny considering Qt itself is part of the LSB! -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
