[CentOS] cups and LSB 3.2; was: Inquiry:yum? - hijack

Thu Dec 24 14:43:19 UTC 2009
R P Herrold <herrold at owlriver.com>

On Thu, 24 Dec 2009, Rob Kampen wrote:

> Forgive me for thread stealing - lsb  3.1 is the current CentOS supported 
> version.
> I have some postscript / cups / printer drivers that insist on lsb 3.2 - 
> anyone know if this is possible?

> TIA Rob

This (LSB 3.2 -- last in the 3 series) is not really bleeding 
edge [LSB 4 just got its first refresh in the 4 series, 4 
having been out about a year], but the LSB intentionally lags 
to get a superset of distributions observed practice in Linux, 
rather than pushing development

The printer driver folks are pushing (Apple 'bought' cups a 
couple years back and are pushing) new versions -- consider 
this:

Date: Thu, 17 Dec 2009 15:10:42
From: Till Kamppeter <till.kamppeter at elided>
To: lsb-discuss at lists.linux-foundation.org,
Subject: lsb-di]  Uplift to OPVP 1.0 in LSB 4.1?

Hi,

at OpenPrinting we are currently approving OpenPrinting Vector 
(OPVP) as official standard, and so the question came up on 
which version of OPVP are we in the printing requirements of 
the LSB and whether we can uplift to 1.0 if needed/possible.

In Ghostscript OPVP 1.0 was introduced with the 8.63 release 
in the beginning of August 2008. Do all the enterprise distros 
under consideration of the LSB already ship Ghostscript 8.63? 
If so, I suggest that we uplift to OPVP 1.0.

--------------------

and frankly this will cause pain as ISV's and 
enterprise distributions are really not set up to 'chase' 
development [not economically justifiable, as it explodes the 
'support matrix'].   Both Linux Standards Base, and Open 
Printing are housed at the Linux Foundation presently, but it 
is not a good fit as they have conflicting mandates as to 
pushing

A grand total of ZERO applications have certified to 3.2
http://ldn.linuxfoundation.org/lsb/certified/applications?filter0=**ALL**&filter1=3721
and the same number to 4.0.  That said there is exactly ONE 
under 3.1

I count 17 distributions certified under LSB 3.1, one under 
3.2, and five to 4.0 ... NOT including RHEL for the last two items. 
While there has been much talk talk from the LF 
representatives about 'privately engaging' CentOS' upstream, 
and my sporadic efforts to drag the issues into the feeder 
Fedora space attention, frankly there is nothing much to show 
for it so far.

One has to ask if the LSB is even relevant.

I would note that with minimal changes, CentOS 5 can be made 
to pass (with minimal exemptions) the LSB 4 test suite in 
trials, and that CentOS 4.2 is used in day to day testing at 
the LSB's test boxes, the disinterest in certifying to the 
LSB at CentOS' upstream is similarly not publicly obvious.

Really and truly, until large entity, commercial purchasing 
agents of enterprise Linux distributions start to insert a 
clause like:

 	The provided software from the Provider shall at all
 	times during the life of this contract conform to the
 	then current Linux Standards Base then-current standard,
 	and be noted as so certified at the the Linux Standards
 	Base website.  There shall be a 'recertification window'
 	of six months following each LSB release and each
 	'point update' or 'refresh' of the same.  The failure to
 	maintain such certifications shall constitue a tender
 	of a 'non-confoming' performance and goods under this
 	contract, and if permitted to remain uncured for thirty
 	days after notice from Purchaser to Provider, shall
 	give rise to remedies to the Purchaser hereunder.

The LSB 'carrot' of interoperability is unappealing to a 
Distribution, as all it does is make an offering 'less 
sticky' and permit easier transitions away and substitutions. 
As the Enterprise Linux market share leader in many segments, 
CentOS' upstream has an incentive to ignore 'chasing' the LSB 
certifications.


The tried and true method to solve this is to back build from 
other's later released sources (hopefully already packaged -- 
I see Oracle's EL in there and those sources should build on 
CentOS); failing that, solving the Fedora/RawHide chain _may_ 
be possible, but as Fedora seeks to be very fast moving, they 
unavoidably avoid providing huge dependency chains.

Perhaps I should start a sub-project to try to carve away the 
GUI 'Fedora fluff' in packaging from the TUI server 'meat and 
potatos' with some sub-packaging breaks and alternatives.  ;)

-- Russ herrold
 	herrold at owlriver dot com