FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

LinkBack Thread Tools
Old 12-24-2009, 01:43 PM
R P Herrold
Default cups and LSB 3.2; was: Inquiry:yum? - hijack

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

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


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

A grand total of ZERO applications have certified to 3.2
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

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
CentOS mailing list

Thread Tools

All times are GMT. The time now is 12:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org