On Wed, 9 Dec 2009, MHR wrote:
> $ yum list | grep -i lsb
> redhat-lsb.i386 3.1-12.3.EL.el5.centos
installed
> redhat-lsb.x86_64 3.1-12.3.EL.el5.centos
installed
when a non-CentOS packaging calls for a CentOS provided
package by an unknown name, this is in no way a CentOS issue
-- look to the packager.
Debian calls its developmental header containing packages by a
shorter form -dev, rather than the -devel that Red Hat derived
use.
The point releases in LSB are largely minor tweaks, and the
major level should provide a stable API across its life. We
are just through about a year in the 4.0 level, and the 4.1
has recently released, as I recall. there is just ONE
_application_ certified to that level, last time I looked, but
the later spec is out there.
Has Google submitted or represented its binary packaging is
compliant at the LSB 3.2 level? Note that there is no SOURCE
packaging LSB API, nor direct naming requirements on
dependencies outside of the lsb- namespace in the LSB
standard.
> I'm not that familiar with lsb, but from what I can find, it
> does not seem like it would be a good idea to install a more
> recent version of lsb than the official release, or am I way
> off base here?
'I am not familiar' with something, but I can fix it with a
hammer, I think. hmmm.
Damage your system's integrity as you prefer. But the better
fix is to simply edit the foreign .spec file in question to
delete the unknown form, and add in its place on that is known
under CentOS. No idea what the API Google wants is, but then,
that is a foreign package. Ask them.
No protocol does, and I have argued elsewhere, can cover all
possible variances that any Linux distribution can come up
with for build system dependencies, as package names flatten
away per file SOnames, API changes, and much more. The index
is too coarse to express the richness of all the possible
variants
Having served on the weekly LSB conference call, at the OLS
sessions, and so forth for more years than I care to remember;
knowing that a CentOS 4.2 platform is used by the LSB staffers
for conformance testing; having run CentOS through the LSB
checker regularly for years and filed 'trail-head' bugs to note
issues [I saw that Stew at IBM replicated one I filed a year
ago just yesterday in the LSB bug tracker], knowing that
someone one (probably Mike Harris) probably already has the
matter solved with patches, I would not tamper with the
'redhat-lsb' level package CentOS ships.
I would instead find out if the 'versioned' at '3.2' lsb is
really needed, or simple bad packaging. Fedora is full of it
and in denial about drilling such out [it also has the nice
from Fedora's point of view knock on effect of lock-stepping
casual packagers into following the 'latest and greatest'
model of Fedora (and making Fedora unsuitable for long lived
deployments, aiding sales of other products in fedora's
owner's portfolio), and to a lesser degree products stabilized
out of Fedora] -- no reason to think Google does not have
unneeded versions present as well
-- Russ herrold