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