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