[lsb-discuss] LSB 4.0 and printing

Vladimir Rubanov vrub at ispras.ru
Thu Mar 27 03:59:33 PDT 2008

Well, at the database level it is possible to tweak for example in the
following way:
1. Make a "Trial Use CUPS Module" and mark it as trial use (currently we do
trial use/mandatory separation at the module level only)
2. Add new "libcups-1.2" record (in addition to mandatory "libcups" but with
different name by adding the version suffix) and assign it to the trial use
3. Make necessary binding of interfaces through the LibGroup and LGInt
tables by creating new records linking to the libcups-1.2 (it is Ok to have
one interface linked to two libraries in DB schema thanks to the LGInt table
though need to check with Denis if it would crash any script or Navigator).
4. There may be a problem with headers - so, to prevent inclusion of trial
use interfaces in header generation, we would need NOT to assign them to any

But I would actually question if we really need to go this way - because if
the value of having two CUPS versions (one mandatory, another trial use) is
mainly in doing preparation for LSB 5.0 to make it easier for LSB 5.0 to
include CUPS 1.2 by just moving from trial use to mandatory, then coping
with the scenario presented above is not technically justified as we would
get more problems in this scenario compared to just uplifting CUPS in its
proper time because uplifting libraries should be highly automated by that
time and should take minimal efforts at least for the DB update part.


> -----Original Message-----
> From: lsb-discuss-bounces at lists.linux-foundation.org [mailto:lsb-discuss-
> bounces at lists.linux-foundation.org] On Behalf Of Wichmann, Mats D
> Sent: Thursday, March 27, 2008 2:49 AM
> To: Theodore Tso
> Cc: printing-architecture at lists.linux-foundation.org; lsb-
> discuss at lists.linux-foundation.org
> Subject: Re: [lsb-discuss] LSB 4.0 and printing
> > So it would be difficult even if the newer (trial-use) version of the
> > component is a strict superset of the mandatory component?
> >
> > I can understand that if an interface has actually *changed* between
> > the two versions, life would be hard; but if it's just a matter of
> > marking some interface as trial-use, and others as required, would
> > that still be hard?
> It removes one level of complexity, indeed.  ISP-RAS has actually
> become the masters of the database schema so we should wait on their
> commentary, but the way I see it, we can currently flag individual
> bits with the LSB version in which they appear, and we can flag
> higher-level components as included or optional.  What we're talking
> about for this behavior is a higher-level component that has two
> shadings: libfoo, when included in "LSB required components" has
> one set of stuff; and libfoo, when included in "LSB trial-use
> components" has a different set of stuff.  As a database /idiot/
> (yes, I proudly admit it!), I don't see how to do that; like I say,
> let's wait for a while to see if there are more educated comments.
> -- mats
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

More information about the lsb-discuss mailing list