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

[Pete Z. <pz...@us...>]

Till,
Just wanted to get the naming convention changed for Omni.
We have changed to have Omni build as a non-debug build so until
we start putting in a bunch of new devices and/or function, it would be
nice if we could use omni-stable instead of omni-unstable.  We
will be adding unstable or devel to our CVS later.

All,
Another thing is that omni is not driven by the LD_LIBRARY_PATH
for loading and now loads out of the /opt/Omni/bin directory.  Sounds
like having multiple versions will require over-rides on where the
different
versions will live once we do provide multiple levels.
Lastly, there is a lot of work has gone into standardization of formnames
and some of the other parameters via UPDF, IPP, and UPNP.  We should
start looking at aligning a number of items so that we can make it much
easier to be able to manage and package the driver support.  Whatever
can be done across the projects for standardization will help anyone
writing tooling to utilize any of the projects simplify their work (ours
too in the
long run).
Any thoughts on what would be helpful from a standardization perspective?
It would be good to decide what would be the best direction to take for
the future along with defining an easy way to update properties and capa-
bilities if needed in a multi-user environment should the need arise.

Thanks,


Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...


Till Kamppeter <til...@gm...>@linuxprinting.org on 10/30/2001
06:11:07 PM

Sent by:  foo...@li...


To:   Grant Taylor <gt...@pi...>
cc:   Robert L Krawitz <rl...@al...>,
      gim...@so..., Pete Zannucci/Austin/IBM@IBMUS,
      Omn...@so...
Subject:  [Foomatic] Re: Problem on the stp web page/with Omni



So I will make it this way:

The following driver names will be used:

    gimp-print
    gimp-print-unstable
    omni-unstable

gimp-print will always carry the data of the newest GIMP-Print
(currently 4.2.x). gimp-print-unstable will carry the newest release of
the unstable series (currently 4.3). From Omni there is only a
development version, so there is only an "omni-unstable" driver entry.

Updating will not be done by the usual install script for the rest of
the site. It will be done by a special script, triggered by one of the
following mechanisms:

    1. Manually when we get notice of a new release of one of the
       drivers. For this we need the info of a new release appearing as
       fast as possible, also from the Omni folks.

    2. A cron job checks the download sites of Omni and GIMP-Print. When
       a new release appears, the update starts.

    3. The server account is subscribed to the GIMP-Print and Omni
       mailing lists and a script is started through the ~/.forward file.
       When a mail announcing a new release arrives, the update is
       triggered. This requires the subject line of the announcement
       following certain rules, as always being:

          ANNOUNCE: gimp-print-4.2.1 released!

The script should do the following:

    1. Download new driver release

    2. "make" but not "make install" i

    3. Remove old option and driver XML files from server.

    4. "foomatic-kitload" the new Foomatic data.

    5. e-mail the successful execution to Grant and me.

If one of these steps failed the script should not execute any
subsequent steps and mail a log to Grant and me.

This keeps the server always as up-to-date as possible, especially when
the script is triggered by a mailing list announcement or by an hourly
cron job.

For this the authors should cooperate by providing machine-readable
announcement titles, easy recognizable robot-downloadable source
tarballs, foomatic data being built always in the same directory, always
the same steps for building being used.

The authors should also have a decent comment in the driver XML files.
It should give a good, human-readable description of the driver, tell
that the Foomatic data is only for the current release (include version
number here), cross-reference between development and stable release
with links, warn users about possible bugs in unstable and that unstable
can be useful for them when stable does not support their printer.

WDYT about that?

    Till


Grant Taylor wrote:

>>>>>>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.
>


_______________________________________________
Foomatic-devel mailing list
Foo...@li...
http://www.linuxprinting.org/cgi-bin/mailman/listinfo/foomatic-devel