[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Grant T. <gt...@pi...>]

>>>>> Till Kamppeter <til...@gm...> writes:

> I would suggest to always have the newest GIMP-Print/Omni Foomatic
> data online and some older versions (3 or so). The older versions
> should be chosen depending on when changes to the Foomatic data of a
> certain GIMP-Print version occur. Every time when a new GIMP-Print
> version appears and its Foomatic data is not compatible to the
> previous version, a new Foomatic data set should be added. Then also
> the oldest can be removed. The GIMP-Print 4.0 data should conserved
> for some more tims as "gimp-print-4.0", for GIMP-Print 4.2.0 there
> should be a "gimp-print-4.2.0", when 4.2.2 will need new Foomatic
> data there will be a "gimp-print-4.2.2", if there are more than
> three driver entries for GIMP-Print 4.2.x, the oldest will be
> removed.

Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
"omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
perhaps "-devel".

When a user installs a new gimp-print foomatic kit, make kitload
automagically uninstall the previous one, and respin all existing
configurations against the new data.

When gimp makes a new release, switch the website to that data.  Don't
try to track all manner of previous releases; that's hopeless.  Just
flog gimp-print binary distributors into shipping the foomatic kits no
matter what else they may do.  Perhaps Robert would put a two-line
"thou shalt configure your gimp-print thusly for binary distribution"
blurb in his readme.

> All options must be versioned, too (ex: option ID:
> "gimp-print-4.2.0-PageSize", file name:
> "gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
> "Page Size"), so that the different GIMP-Print versions do not
> interfere.

Yes, but only inasmuch as there is a normal and -unstable driver name.

Don't go all whacky putting in actual numbers; this will break many
things including upgrades.

The gimp-print release cycle allows the foomatic generator code there
to know if it needs to put -devel on the end or not, so this can be
all automagic.  Dunno what goes on in OMNI.

> This requires from both the authors of Omni and GIMP-Print that they
> inform Grant and me about every release and which release needs new
> Foomatic data, so that we can keep linuxprinting.org up-to-date.

For all releases just do the update exercise regardless; you pretty
much do this now as a function of making libgimpprint and omni rpms.

> The impact for the database is probably not so high, the server has 
> plenty of resources

That's not the point.  *We* don't scale that way, and even if we were
to arrange to it wouldn't actually solve a problem.

>> Yes, this highlights one thing we need in foomatic: dependency
>> checks.  PDQ has a scheme for this, whereby you plug in shell code to

> You mean that Foomatic should check which drivers are installed on
> the local machine (GS driver in "gs --help", filter in $PATH, for
> UPP driver upp file available, and version check, shell script for
> doing these checks should be in a field of the driver's DB entry)
> and "foomatic-configure -O" only list ths combos which will work on
> the current system?

Foomatic shouldn't be that clever.  It should simply offer a warning
at configure time saying "such-and-such driver is not present, setting
up anyway".  People can either install the driver or pick a different
one.

Not listing it with -O means that people will never figure out that
there is a or a better driver in the world for them.  And the -O is
used for autodetection as well, remember, so there may be no pruning
there.

We can get fancy about how to find and install missing drivers later;
first things first.

--
Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO:  http://www.linuxprinting.org/