[lsb-discuss] Reducing set of distributions in AppChecker and Navigator
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
> 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):
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:
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lsb-discuss