[lsb-discuss] Reducing set of distributions in AppChecker and Navigator

Denis Silakov dsilakov at gmail.com
Wed Jan 18 20:11:50 UTC 2012


On 01/11/2012 05:31 PM, Wichmann, Mats D wrote:
>
> On Wed, Jan 11, 2012 at 6:15 AM, Denis Silakov <dsilakov at gmail.com 
> <mailto:dsilakov at gmail.com>> wrote:
>
>     Hi all,
>
>     While preparing community data update, the following thought have
>     come to our minds - would it make sense to drop some distribution
>     entries that may look superfluous for users?
>
>     For example, currently we have RHEL 4, 4.1, 4.2, ... 4.8. But do
>     we really want all of them? I'd say that for LSB development we
>     don't need the whole history of every RHEL series , but I am not
>     sure about AppChecker users.
>
>     The suggestion is to store only the very first and the very last
>     versions for sequences of updates. That is, for RHEL 4.x we'll
>     have RHEL 4 and RHEL 4.8; for Debian 6.0 - probably 6.0.0 and
>     6.0.3 and so on.
>
>     Does this sound reasonable? Do SUSE guys agree if we drop SLES 10
>     SP1 and SLES 10 SP2, leaving only SLES 10 itself and SLES 10 SP3? :)
>
>     Note that this is primarily the question of usability of bloating
>     distribution list in Navigator/AppChecker. Dropping entries in
>     question won't save much space in the database, since we have good
>     mechanisms of 'data compression' in cases of several similar
>     distributions.
>
>
>
>
> I think in general I like the idea; too much data in tables makes them 
> hard to read.    The bit we'd be missing which /might/ be interesting 
> is version numbers on packages.  Does the navigator have the ability 
> to run a report showing differences between "close" distributions (I 
> can't recall seeing this).  Might be interesting to see Navigator's 
> take on say 4.5 vs 4.6 of something - and then maybe we just toss 
> 4.5....  just thinking out loud.
>
It's not easy to teach Navigator to show such data, but I can generate 
some approximations by myself :)

Here is comparison of versions of components interesting in the context 
of LSB (5 tables - sles10, rhel4/5 and debian5/6):
http://dsilakov.ru/distr_comps.html

Hopefully highlighting is almost self-explaining - green is good, red is 
not:) The only really significant change (that did affect LSB 
development) is Qt update in SLES 10 SP2. It is likely that we want to 
store this info in the db.

There is also a page reflecting changes in the whole system, not only in 
the LSB-related components:
http://dsilakov.ru/distr_libs.html

The latter page says that most of successive releases are very close to 
each other (~98-99% of interfaces are the same - so for 99% of apps it 
doesn't make difference if they run in one service pack or another). 
Note that in the context of LSB that page should be treated carefully. 
For example, one can see that between rhel 4.5 and 4.6 'libcairo.so.2, 
libpangocairo-1.0.so.0' were added, as well as lots of LSB interfaces. 
But if we look in details (in Navigator) we'll see that it was not 
gtk/cairo uplift; instead, a new gtk/cairo were packaged as a part of 
'evolution'. That is, RedHat decided to uplift (or add?) evolution which 
required new gtk/cairo; they didn't want to uplift system gtk, so they 
just packaged a separate gtk version within the evolution. Navigator is 
not so smart to handle such situations, but AppChecker is smarter and 
tries to take into account ldconfig configurations (it is likely that 
ldconfig doesn't pick up gtk from evolution in rhel 4.6).

On the basis of these investigations, I'd say that it is safe to store 
only the first and the last versions of series for Debian, as well as 
for RHEL. SLES is questionable; in the context of LSB history, I'd like 
to keep at least SLES 10 SP2 data (and probably other 10 SP*, as well - 
to avoid questions like 'are you sure that qt was updated in sp2, not in 
sp1?').

An important note is that one should distinguish data stored in the LSB 
DB and data used by the Linux AppChecker. When generating AppChecker, we 
can drop certain distributions. (As for Navigator - it straightforwardly 
displays everything that exists in the database).

So the *bottom line* - for the next update of the LSB DB data, I will 
probably follow the way suggested in the initial mail ("store only the 
very first and the very last versions for sequences of updates") for 
Debian and RHEL, but leave the whole history for SLES 10.

But it is still the open question (for me, at least:)), which SLES 10 
variants we want to see in the AppChecker - 10 and 10 SP4, all 5 
versions, SP4 only, or probably 10, 10 SP2 and 10 SP4?

-- 
Regards,
Denis.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120118/897ba090/attachment.html>


More information about the lsb-discuss mailing list