Is lsb 3.2+ detrimental to CentOS 5.4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux