Cindy,
See below .....
Cynthia Eastham wrote:
> Thank you so much for you comments Paul!
>
> Paul Cunningham wrote:
>>
>> Find some comments on this in-line below. They are all fairly minor,
>> or nit-picking, so feel free to ignore them if you want to. See below
>> ...
>>
> I would never ignore your comments... all are very much appreciated!
> :) Although, seeing as this is my first time posting to this alias, I'm
> not sure how to actually display the latest version of the document. I
> have the design doc under sccs control. I could send out an updated
> version containing any updates to your comments, but would everyone want
> to see change bars?
I personally don't like change bars - yes they are good in the first
instance but after that they are just clutter in a document.
> I'm not quite sure how to do this with ascii text
> files. Suggestions would be welcome. For now, I'll just (or at least
> try to) respond in-line.
>
>>
>>
>> Cynthia Eastham wrote:
>>
>>>
>>> I'd like to announce a new, much needed, printing project: PPD Cache
>>> Management. I am attaching a draft of the design document for your
>>> review. This is a small project which we hope to complete within the
>>> next month. In a nutshell, this will allow a PPD file to be added to
>>> the system, and the new printer information reflected in the cache
>>> file used by the printmgr to display available printer information
>>> the user.
>>>
>>> Thank you,
>>> Cindy
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> PPD Cache Manager Project Design
>>>
>>> BACKGROUND
>>> In order to provide support for a wide range of printers, the Solaris
>>> Print
>>> System has the ability to use Postscript Printer Description (PPD)
>>> files which
>>> can be used as a per queue configuration option. A set of gzipped
>>> PPD files is
>>> delivered with Solaris in the "system" directory under the PPD
>>> repository
>>> (/usr/lib/lp/model/ppd), as well a private cache
>>> (/usr/lib/lp/model/ppd/ppdcache) file of the printer information
>>> contained
>>> in each of the delivered PPD files.
>>>
>>> On the command line, a user can add, or modify, a print queue to use
>>> a PPD file
>>> using the lpadmin -n option. An unzipped copy of this PPD file is saved
>>> under /etc/lp/ppd and the original path of the PPD file is placed in the
>>> printer configuration file
>>> (/etc/lp/printers/<printer>/configuration). The
>>> lpadmin -n option allows users to specify PPD files not delivered
>>> with Solaris,
>>> just so long as the PPD file path is valid and the path ends with
>>> either a
>>> ".ppd" or ".ppd.gz" extension.
>>>
>>> With the Solaris Print Manager (printmgr) GUI, a graphical tool for
>>> managing
>>> printers under Solaris, printer information from available PPD files is
>>> displayed to assist with the addition or modification of a print queue.
>>> To quickly display printer information, the printmgr obtains PPD file
>>> printer
>>> information from the ppdcache file.
>>>
>>> With the number of printers constantly growing, the set of PPD files
>>> delivered
>>> with Solaris can quickly become out-of-date. While a PPD file not
>>> delivered
>>> with Solaris can be added to the system using the lpadmin -n option, a
>>> gzipped version is not added to the PPD repository, and more
>>> importantly, the
>>> ppdcache file utilized by the printmgr is not updated with the new
>>> PPD file
>>> information. Since there is currently no means to update the
>>> ppdcache file,
>>> users are frustrated that they are unable to add a print queue for their
>>> new wizbang printer using the printmgr. See CRs 6236968 "no
>>> documented way
>>> to add PPD file to ppdcache", and 6302561 "gimpprint drivers
>>> unavailable/PPD's
>>> missing/ijsgimpprint missing from release".
>>
>>
>>
>> FYI, If I remember correctly the reason why no gimp-print ppd files
>> were delivered (in SUNWgimpprint) was because at the time (2+ years
>> ago) the gimp-print opensource project had stopped delivering them
>> with their package - I think the plan was that they would be delivered
>> with foomatics but not the version that was integrated into the wos at
>> the time. I think for the Companion CD (CCD) version I borrowed them
>> from any earlier version of the gimp-print package. I don't know where
>> they are now because I don't think they are still in the latest
>> foomatic stuff.
>>
> Thank you for the info Paul... good history to know. I believe this
> will be helpful information to know as we are thinking of redoing the
> packaging.
>
>>>
>>> One additional note to be made is that the Free Standards Group (FSG)
>>> OpenPrinting Group is working on standardizing some installation
>>> locations
>>> for PPD files and print drivers so that printer vendors and driver
>>> suppliers
>>> have a common place to install regardless of print service or OS
>>> distribution.
>>> As of the writing of this document, the following would be the
>>> location of
>>> PPD files:
>>>
>>> /usr/share/ppd/{supplier}/{language}/{manufacturer}/{manufacturer}-{model}[-{extra}]-{language}.ppd
>>>
>>>
>>>
>>> where
>>> - {supplier} is the name of the manufacturer or project that
>>> supplied
>>> the files
>>>
>>> - {manufacturer} is the manufacturer (MFG) value from the
>>> IEEE1284 DeviceId
>>>
>>> - {model} is the model (MDL) value from the IEEE1284 DeviceId
>>> language is the language portion of a locale extra is supplier
>>> defined
>>>
>>> - whitespace and dash(-) are replaced with underscore(_) in {}
>>> values
>>> For example:
>>> /usr/share/ppd/foomatic/HP/HP-LaserJet_4050-o_pxlmono-en.ppd
>>
>>
>>
>> Shouldn't this example path have a {language}/ dir in it
>> (foomatic/en/HP) as per above?
>
>
> Yep! I'll add it in. From the latest discussions, it sounds like the
> {language} directory may go away. I'll wait until official notice has
> gone out to update the document to take out the {language} directory.
I personally would prefer to see {language}/ removed as it's also in the
ppd file name.
>
>>
>>>
>>>
>>> DESCRIPTION
>>> This project will provide the user with a public tool (ppdmgr) to add
>>> PPD
>>> files to the to the PPD repository and reflect (update or rebuild) the
>>> PPD repository modifications in the ppdcache file. lpadmin will be
>>> modified to exec the new tool to add the PPD file into the PPD
>>> repository,
>>> allow the specification of a "label" (discussed below), and to modify
>>> the
>>> path to the original PPD path in the printers configuration file.
>>> printmgr will be modified to display the "label" information.
>>>
>>> As noted above, this project will be to provide the ability to add
>>> PPD files
>>> to a system running Solaris. The ppdmgr will be able to run as root
>>> or lp.
>>> In the future, this capability can be opened up to non-root
>>> privileged users.
>>> Other possible actions which can be added in the future include delete,
>>> and query or list actions.
>>>
>>>
>>> The directory tree of the PPD file repository currently delivered
>>> with Solaris
>>> is as follows:
>>>
>>> /usr/lib/lp/model/ppd/
>>> / / \ \
>>> / / \ \
>>
>>
>>
>> diagram got me a bit confused to start with, it might be better as ...
>>
>> /usr/lib/lp/model/ppd
>> |
>> |
>> -------------------------------------
>> | | | |
>
>
>
> Good suggestion. I'll redo the diagrams with your suggested method.
>
>>> manufacturer/ ppdcache system/ user/
>>> |
>>> |
>>> <Manufacturer>/
>>> / | \
>>> / | \
>>> <ppd_file1> <ppd_file2> ... <ppd_fileN>
>>>
>>> where Manufacturer is determined by reading the Manufacturer field from
>>> the PPD file and <ppd_fileN> is a gzipped PPD file with the extension
>>> ".ppd.gz".
>>> This directory structure will be modified to align with the location
>>> decided
>>> upon by FSG OpenPrinting Group, and to allow for package adds and
>>> deletes,
>>> updates, and patches, as well as to allow diskless clients to also take
>>> advantage the ability to add PPD files and update the ppdcache
>>> /usr/lib/lp/model/ppd/manufacturer, /usr/lib/lp/model/ppd/user,
>>> and /usr/lib/lp/model/ppd/ppdcache will no longer be needed.
>>>
>>>
>>> As specified by FSG OpenPrinting Group, all PPD files will now be
>>> delivered
>>> under /usr/share/ppd/<supplier>. Thus, the directory "system" under
>>> which
>>> PPD files are currently delivered with the Solaris, will now be a
>>> symlink
>>> to /usr/share/ppd. With this project, the directory tree of the PPD
>>> file
>>> repository will be modified to include 2 new repository areas: one new
>>> repository area, /usr/share/ppd/, will be for the delivery of PPD files
>>> via pkgadd or patch, cache files associated with the delivered PPD files
>>> (found under /usr/share/ppd/ppd/ppdcache/) as well as a new
>>
>>
>>
>> typo I think - share/ppd/ppd/ppdcache -> share/ppd/ppdcaches/
>
>
>
> Yes... my fingers got carried away with typing "ppd" :) I'll take out
> the extra "ppd".
>
>>
>>> SUNWManufAliases file (see New Manufacturer Aliases File
>>> section below for more information on this new file), and the other new
>>> repository area, /var/lp/ppd, will be to store PPD files added using the
>>> new ppdmgr utility, the ppdcache file, as well as intermediary caches
>>> used
>>> to update the main ppdcache file more efficiently. The proposed
>>> directory tree
>>> of the PPD file repository delivered with Solaris is as follows:
>>>
>>> /usr/lib/lp/model/ppd/system---- /
>>> /
>>
>>
>>
>> I assume this means symbolic link ?
>
>
>
> Yes, didn't quite know how to make it look like a symbolic link. I
> believe I mention that it's a symbolic link in the text. Perhaps I
> should just take it out of the diagram all together?
or explicitly say it in the diagram, eg.
/usr/lib/lp/model/ppd/system----
/
(symbolic link)
/
/--->/usr/share/ppd/
>
>>> /
>>> /
>>> / `-->
>>> /usr/share/ppd/
>>>
>>> / / / \ \
>>> / / / \ \
>>> <supplier1>/ ... <supplierN>/ ppdcaches/
>>> SUNWManufAliases
>>> | \ \
>>> | \ \
>>> <language>/ <language>/
>>> <supplier1>...<supplierN>
>>
>>
>>
>> How will a manufacturer's package that delivers a
>> ppdcaches/<supplier>/ cache file append this to the main
>> /var/lp/ppd/ppdcache file used by printmgr?
>>
>> Also I assume these ppdcaches/<supplier>/ cache files are fixed and
>> will not change during run-time (that goes into
>> /var/lp/ppd/cache/<label>/ ?
>>
> If there is a ppdcaches/<supplier>/cache file, then this file, or we
> might make a copy of it in /var/lp/ppd/caches/<label>, will be used to
> updated the golden ppdcache (/var/lp/ppd/ppdcache) file used by the
> printmgr. Yes, the ppdcaches/<supplier>/cache files are fixed. Only
> cache files under /var/lp/ppd/caches (in addition to the golden ppdcache
> file) can change during run-time. It's my undertanding that with
> diskless clients, /var is writeable, /usr is not.
>
>>> | |
>>> | | <Manufacturer>/
>>> <Manufacturer>/
>>> / | \ / | \ / |
>>> \ / | \ <ppd_file1>...<ppd_fileN>
>>> <ppd_file1>...<ppdfileN>
>>>
>>>
>>>
>>> /var/lp/ppd/
>>> / / | \ \ \
>>> / / | \ \ \
>>> caches/ ppdcache user <label1> ... <labelN>
>>> / | \ | \ ...
>>> / | \ | \ ...
>>> <label1> ... <labelN> <Manufacturer>/ <Manufacturer>/
>>> / | \ / | \
>>> / | \ / | \
>>> <ppd_file1>...<ppd_fileN>
>>> <ppd_file1>...<ppdfileN>
>>>
>>>
>>>
>>> A directory "user" will be added under /var/lp/ppd to store PPD files
>>> added by users where no label is specified. In addition, user specified
>>> label directories will be created under /var/lp/ppd when a user adds a
>>> PPD file using the ppdmgr with a specified label. For more information
>>> on "label", see the Introduction of "label" section below.
>>> The ppdcache file, used by the printmgr, will now be maintained under
>>> /var/lp/ppd/ppdcache, as well as intermediary cache files used to
>>> update /var/lp/ppd/ppdcache. These intermediary cache files will be
>>> maintained under a directory, /var/lp/ppd/caches, for each labeled
>>> grouping
>>> of PPD files.
>>> The following sections provide a more detailed description of the new
>>> label
>>> grouping of PPD files, a new file containing known manufacturer aliases,
>>> new cache files, new ppdmgr utility, as well as modifications to lpadmin
>>> and printmgr.
>>>
>>> Introduction of "label"
>>> -----------------------
>>> With this project, a new term "label" will be used to describe a
>>> grouping of
>>> PPD files. The label refers to a user selected directory name in the
>>> PPD
>>> repository. Thus, every <supplier> directory delivered under
>>> /usr/share/ppd will automatically become a label. Labels allow
>>> users to organize their PPD files under a label of their own
>>> choosing, and
>>> to easily identify their label when adding or modifying a printer using
>>> the printmgr. When a user chooses to add a PPD file under a specified
>>> label that does not exist yet on the system, a new directory will be
>>> created
>>> under /var/lp/ppd/user with the specified label name. The PPD file
>>> will be
>>> added under the directory with the specified label name.
>>>
>>> As stated above, every <supplier> directory under /usr/share/ppd will
>>> automatically be considered a label name. For example, for foomatic
>>> supplied
>>> PPD files delivered under /usr/share/ppd/foomatic, the label is
>>> considered
>>> to be "foomatic". When choices are provided to the user when adding or
>>> modifying a printer using the printmgr, the label can be displayed along
>>> with the PPD file selection to allow the user to distinguish from
>>> possible
>>> duplicate manufacturer entries.
>>>
>>> With this project, any labels begining with the string "SUNW" are
>>> reserved,
>>> and may not be specified by users with the ppdmgr utility. In addition,
>>> the label "all" is also reserved, and only selectable under certain
>>> conditions. These conditions are discussed in the description of
>>> each of
>>> the options for the new ppdmgr utility below.
>>>
>>>
>>> New Manufacturer Aliases File
>>> -----------------------------
>>> In addition, this project will introduce a new private file,
>>> /usr/share/ppd/SUNWManufAliases, which will be used to keep track of
>>> possible aliases used in PPD files for the Manufacturer entry. A one
>>> line entry for each manufacturer in which multiple aliases exist is
>>> added to
>>> this file. Each line will have the form
>>> <Manuf>|<alias1>[[|<alias2>]...[|<aliasN]]
>>> For example, the following will be the contents of the ManufAliases file
>>
>>
>>
>> .... shouldn't that be SUNWManufAliases (and elsewhere)
>
>
>
> Yes.
>
>>
>>> to be delivered with this project.
>>>
>>> tamarisk# cat SUNWManufAliases
>>> HP|hewlett-packard Okidata|oki
>>> Minolta|minolta-qms
>>>
>>> If a case insensitive search for the Manufacturer entry from a PPD file
>>> indicates it has an alias in the ManufAliases file,
>>> then the first entry on the line will be used instead of the alias.
>>> If a
>>> PPD file contains a Manufacturer name of HEWLETT-PACKARD, then the
>>> actual
>>> Manufacturer name used is HP. Note: this is only used to store PPD
>>> files
>>> added to a label using the ppdmgr utility.
>>
>>
>>
>> Is there going to be a utility the user (printer manufacturer, etc)
>> can use to update this SUNWManufAliases file to add their own stuff?
>> If so maybe the file should be in /var
>
>
> I originally assumed this would only be a Sun delivered thing. Maybe we
> can think about this one. If a <supplier> delivers a new alias entry,
> then it could possibly collide with another... this would probably only
> happen in the case there is a new <Manuf>.
or where a company is taken over by another company and they want to
change the 'name' they are known by.
> Maybe this is a problem,
> maybe it's not.
yes it would only become a problem when someone wanted to change its
content which would probably be very rarely.
> We could treat the manufacturer aliases just as we do
> caches by providing a ManufAliases directory where suppliers can deliver
> entries. A ManufAliases file could then reside under /var/lp/ppd which
> combines all the different supplier entries.
>
>>
>>>
>>> New Caches Directory and Cache Files
>>> ------------------------------------
>>> The format of the ppdcache file used by the printmgr will remain the
>>> same as delivered today, however will be moved from
>>> /usr/lib/lp/model/ppd/ppdcache to /var/lp/ppd/ppdcache. Suppliers can
>>> deliver a cache of the PPD files they deliver in
>>> /usr/share/ppd/ppdcaches/<supplier>. Cache files delivered from
>>> suppliers
>>> will be used to update and rebuild the ppdcache file used by the
>>> printmgr. If a cache file is not delivered with a supplier's PPD files,
>>> then one will be generated and located in /var/lp/ppd/caches/<supplier>.
>>
>>
>>
>>> All labeled cache files which are generated to reflect the printer
>>> information for all PPD files associated with the label in the PPD
>>> repository.
>>
>>
>>
>> Not really sure I understood the above sentence
>
>
>
> Yeah, lots of words but no real meaning :) I think what I was trying
> to get across was that when a cache file is generated, the golden
> ppdcache file will also be updated to reflect the new cache file entries.
>
>>
>>> In order to update the ppdcache file, intermediary cache files,
>>> of the same format, will be maintained in a private directory
>>> /var/lp/ppd/caches. For each labeled grouping of PPD files a cache file
>>> with the same label will exist under the cache directory. Each
>>> <supplier>
>>> of PPD files will be considered a label. For example, a cache file
>>> for the
>>> supplier "foomatic" PPD files will be maintained under
>>> /var/lp/ppd/caches/foomatic. The location of the ppdcache file used by
>>> the printmgr, and updated via the ppdmgr, will be /var/lp/ppd/ppdcache.
>>> When the ppdcache file needs to be updated or rebuilt, the intermediary
>>> cache file under /var/lp/ppd/caches are used to update or build the
>>> ppdcache
>>> file efficiently.
>>>
>>> PPD Manager
>>> -----------
>>> The PPD Manager (ppdmgr) tool will be delivered as
>>> /usr/lib/lp/bin/ppdmgr with
>>> a symlink from /usr/sbin/ppdmgr to /usr/lib/lp/bin/ppdmgr. With this
>>> project,
>>> the user may add a PPD file to the system, optionally supply a label to
>>> associate the PPD file with, request an update of the cache
>>> associated with
>>> a specific (or all) label, or request an rebuild of cache associated
>>> with a specific (or all) label.
>>>
>>> In general, if an error message is displayed, it will be displayed on
>>> stderr,
>>> and the ppdmgr will exit with and error code. Thus, no logging will be
>>> performed.
>>
>>
>>
>> what state will the cache file(s) be left in if an error occurs while
>> it is updating them?
>
>
> A temporary cache file will be created to maintain all new changes to a
> cache. When all changes to the temporary cache file are complete, then
> the new version will replace the original version. If any errors occur,
> the original version will be maintained.
just as I assume it would do.
>
>>
>>>
>>> The proposed synopsis for ppdmgr:
>>>
>>> ppdmgr [ -a <ppd_path> | -r | -u ] [ -l <label> ] [-w]
>>>
>>>
>>> The following is a more in depth description of each of the proposed
>>> options:
>>>
>>> To add a PPD file to the system
>>> -------------------------------
>>> -a <ppd_file_path>
>>
>>
>>
>> Just wonder if it would be better to use the same option letter (-n)
>> that lpadmin uses for this?
>
>
> I'm not married to -a. I just thought it made more sense. To me -a
> stands for "add". Perhaps a description for -n could be "new ppd"?
They '-n' was only used in lpadmin as there were so few characters left
that could be used (due to lpadmin many-many-many options). Do you know
if Sun (svr4) has some convention on how option letters should be
allocated on command-lines if the same/similar option is used in an
existing utility? Either way is okay with me though.
>
>>
>>>
>>> Copies the PPD file specified in ppd_file_path to the PPD
>>> repository, then updates the cache to reflect the change.
>>> Unless the -l option is also specified, the default
>>> label the PPD file will be associated with is "user".
>>>
>>> Label verification will be performed.
>>>
>>> If a reserved label name "all" or beginning with "SUNW" is
>>> specified, an error message will be printed and ppdmgr will
>>> exit.
>>>
>>> Path verification will be performed.
>>>
>>> If the specified ppd_file_path is not accessible, an
>>> error message will be printed and ppdmgr will exit.
>>>
>>> If ppd_file_path does not end in either ".ppd", or
>>> ".ppd.gz" (gzipped) extension, then an error message
>>> will be printed and ppdmgr will exit. In the future,
>>> support for other extensions such as .ppd.bz (bzipped)
>>
>>
>>
>> shouldn't that be .ppd.bz2
>
>
> Eagle eye! Yep again!
>
>>
>>> can be provided.
>>>
>>> PPD file verification will be performed.
>>>
>>> If the first line of ppd_file_path does not begin with
>>
>>
>>
>> I assume you mean the first line of the contents of <ppd_file_path> here?
>
>
> Yes.
>
>>
>>> *PPD-Adobe: "4.3",
>>> then an error message will be printed and ppdmgr will exit.
>>
>>
>>
>> Are we sure they will always have this in the first line?
>
>
> According to the current spec, yes, otherwise, they aren't a valid PPD
> file.
>
>>
>>>
>>> Other PPD file verification/validation tests can be added
>>> in the future.
>>> The destination path for the copied PPD file will be determined
>>> by the label (-l) name and Manufacturer name contained within
>>> the specified PPD file.
>>>
>>> The Manufacturer name will be read from the PPD file
>>> specified with ppd_file_path. If unsuccessful, an
>>> error message will be printed and ppdmgr will exit.
>>
>>
>>
>> Are we sure that PPD files will always have 'Manufacturer' defined in
>> them?
>>
> Again, I believe this is part of the spec. PPD files must contain a
> Manufacturer name.
>
>>>
>>> Since the Manufacturer name can have multiple aliases,
>>> the Manufacturer name is an alias in
>>> /usr/share/ppd/SUNWManufAliases, the actual Manufacturer
>>> name will be used instead.
>>>
>>> The destination path determined from the above steps is
>>> /var/lp/ppd/<label>/<Manufacturer>/<ppd_file>,
>>> where <ppd_file> is the basename of ppd_file_path.
>>>
>>> Parent directories of the destination path are created,
>>> if needed. If unsuccessful, an error message will be
>>> printed and ppdmgr will exit.
>>>
>>> If a gzipped version (.ppd.gz extension) of
>>> the PPD file already exists in the PPD file repository,
>>> and the gzipped versions are not duplicates,
>>> a message will be printed, and ppdmgr will exit.
>>>
>>> ppd_file_path is copied to the destination path. If
>>> unsuccessful, an error message will be printed and
>>> ppdmgr will exit.
>>>
>>> The update action (see -u) is then applied to reflect the
>>> change in the ppdcache file.
>>
>>
>>
>> Can a user add a ppd file into /var/lp/ppd that is already in
>> /usr/share/ppd with the same name?
>
>
> Yes, this where labels come in though. A user can add a ppd file which
> is under /usr/share/ppd, but it will be added under /var/lp/ppd/user if
> a label isn't specified with -a, or under /var/lp/ppd/<label> if it is.
> When the printmgr is brought up and detects multiple instances, they are
> displayed with the label name.
of course, silly me!
>
>>
>>>
>>>
>>> To specify a PPD repository label
>>> ---------------------------------
>>> -l <label>
>>>
>>> The label is used to group PPD files in the PPD repository.
>>> Opaque to the user, <label> is actually the name of
>>> the <supplier> directory under /var/lp/ppd, i.e.,
>>>
>>> /var/lp/ppd/<label>
>>>
>>> or is the associated intermediary cache file under
>>> /var/lp/ppd/caches/<label> associated with the labeled
>>> grouping of PPD files in /var/lp/ppd/<label>.
>>>
>>> For example, with the following PPD file:
>>>
>>>
>>> /usr/share/ppd/foomatic/en/HP/HP-LaserJet_4050-o_pxlmono-en.ppd.gz
>>>
>>> the ppdmgr would consider "foomatic" to be the label.
>>> The intermediary cache file associated with the "foomatic"
>>> label would be maintained in
>>>
>>> /var/lp/ppd/caches/foomatic
>>>
>>> The specified label must a valid directory name (i.e.,
>>
>>
>>
>> typo "label must a valid" -> "label must be a valid"
>
>
> Ah yes.
>
>>
>>> mkdir() would succeed). However, a label must not be either
>>> "." or "..", and must not contain a slash '/' character.
>>> If an invalid label is specified, then an error message
>>> will be printed, and the ppdmgr will exit.
>>>
>>> Reserved label names include any label beginning with "SUNW",
>>> and may not be specified with -a, -r, or -u.
>>>
>>> Another special reserved label "all" may only be specified with the
>>> -r or -u options.
>>> If reserved label is specified with the -l option, then an error
>>> message will be printed, and the ppdmgr will exit.
>>>
>>>
>>> To request a cache update
>>> -------------------------
>>> -u
>>>
>>> Updates the cache to reflect the printer information from
>>> PPD files in the PPD file repository. This action is also
>>> performed by default after a PPD file is added to the system with
>>> the -a option, or after a cache file was removed when a rebuild
>>> was requested with the -r option.
>>>
>>> The label is used to determine which cache to update.
>>>
>>> If the -l is also specified, and the label is not
>>> a reserved label beginning with "SUNW", then only
>>> the PPD file modifications associated with the
>>> specified label are reflected in the ppdcache file.
>>> Entries associated with other labels will remain
>>> as-is in the ppdcache file.
>>>
>>> If the "all" label is specified with the -l label, then
>>> all PPD file modifications associated with all labels,
>>> with the exception of any labels beginning with "SUNW",
>>> in the PPD repository will be reflected in the ppdcache file.
>>>
>>> If the -l is not specified, then, by default, only the
>>> PPD file modifications associated with the "user" label are
>>> reflected in the ppdcache file.
>>>
>>> Cache files associated with the label are updated.
>>>
>>> To update a cache, any unzipped PPD files in labels under
>>> /var/lp/ppd, are gzipped. If a differing gzipped version
>>> of the file already exists, an error message is printed,
>>> but continues.
>>>
>>> The cache is then sync'd with the list of PPD files
>>> associated with a label.
>>>
>>> A list of PPD files under the label name
>>> either in /var/lp/ppd/<label>
>>> or /usr/share/ppd/<label>,
>>> as well a list of PPD files contained in the
>>> associated labeled cache file in
>>> /var/lp/ppd/caches/<label>
>>> are generated.
>>>
>>> These two lists are compared against each other.
>>>
>>> If a PPD file is associated with the label, but
>>> isn't in the cache file list, then a cache entry for
>>> that PPD file is added to the label cache file.
>>>
>>> If a PPD file is listed in the ppdcache, but no longer
>>> is in the list of PPD files associated with the label,
>>> then the cache entry is deleted from the label cache.
>>>
>>> If a PPD file associated with the label is in
>>> the cache file list, but the ppdcache file entry
>>> information is out-of-date, then the cache
>>> entry is deleted from the label cache and a cache entry
>>> for the newer cache entry is added to the label
>>> cache file.
>>>
>>> All label cache files associated in the PPD repository are
>>> concatenated to produce the ppdcache file.
>>>
>>> To request a cache rebuild
>>> --------------------------
>>> -r
>>>
>>> Rebuilds cache. The rebuild is actually made up of two steps:
>>> remove a cache file associated with a label, then regenerate the
>>> cache file using update (see -u).
>>> A rebuild is very similar to an update, however, can take
>>> quite a bit
>>> more time a cache file associated with a label are totally
>>> regenerated.
>>> When the cache file regeneration is complete, then the cache files
>>> associated with all labels in the PPD repository are concatenated
>>> to produce the ppdcache file.
>>>
>>> The label is used to determine which cache to rebuild.
>>>
>>> If the -l is also specified, and the label is not a
>>> reserved label beginning with "SUNW", then the cache
>>> entries for the specified label are totally rebuilt
>>> to reflect the PPD information from all the PPD files
>>> associated with the specified label.
>>>
>>> If "all" is specified with the -l option, then cache entries
>>> for all PPD files associated with all labels in the PPD
>>> repository are rebuilt except for any labels beginning with
>>> "SUNW".
>>>
>>> If -l is not specified, the default label is "user".
>>>
>>> Delete the label cache.
>>>
>>> Update the label cache (see -u).
>>>
>>> Display Full Path of PPD File in the Repository
>>> -----------------------------------------------
>>> -w
>>>
>>> If specified with the -a option, and the -a option is
>>> successful, then the full path of the PPD file that was
>>> added is displayed on stdout. Otherwise, -w has no affect.
>>>
>>> Other ppdmgr notes:
>>>
>>> Users will be encouraged to add PPD files to the system using
>>> either the lpadmin
>>
>>
>>
>> maybe you should add "(see 'lpadmin Modifications' below)" next to
>> lpadmin as this is new for lpadmin.
>>
>> or the ppdmgr utilities. However, if a
>
>
> I can do that. Although, users already use the lpadmin -n interface to
> add a PPD file to the system, so it's not really new. Only the fact
> that the PPD file information can now be seen with the printmgr, as well
> as the fact that a copy of the PPD file will now be place in the PPD
> file repository is new.
>
>>> PPD file is copied to the PPD file repository under a
>>> non-reserved label, then the next time a ppdmgr update action is
>>> requested, the printer information from the copied PPD file will
>>> be reflected in the cache.
>>>
>>> lpadmin Modifications
>>> ---------------------
>>> The ability to specified a label, as well as to copy a file in the PPD
>>> file repository and update the ppdcache file will be added to lpadmin.
>>>
>>> A new command line option, -y, will be added to lpadmin to allow the
>>> user to specify a label name to associate the PPD file with. The
>>> same rules that apply for the ppdmgr -l option apply for the
>>> lpadmin -y option.
>>
>>
>>
>> if '-y' is not given does it go into label 'user'?
>>
>> What if the user does not want to add the ppd file into the repository
>> (eg. it's a very special unique bodged ppd for a unique print q), can
>> they still do that?
>
>
> Yes, the default is 'user'.
>
> If the ppd file is not copied into the repository, then we cannot
> reliably access that ppd file's information. I think this is exactly
> why label are so good... it allows a user to specify a unique label to
> store there special unique bodged ppd for a unique print queue in their
> own special place by specifying a new label. Maybe I'm missing what you
> are trying to say.
So I think you are saying that if 'lpadmin -n my.ppd' is used it will
always be put into the ppd file repository. What I was trying to get at
is, what if the admin user doesn't want it to go into the repository
because its just a tryout file (wants it kept private from other admins;
once its in the repository any other admin could try to use it), can
he/she still do that? I think the answer is no; and my personal
preference would be, only to be able to make them public via ppdmgr.
>
>>>
>>> lpadmin will be modified to call the new ppdmgr utility to add the
>>> new PPD file to the PPD repository in /var/lp/ppd,
>>> with the associated label and to reflect the addition in the
>>> ppdcache file. If the call to the ppdmgr utility fails, lpadmin
>>> will exit with an appropriate message for the exit status received.
>>>
>>> The PPD path reflected in the
>>> /etc/lp/printers/<printer>/configuration
>>> file will now be the path of the copied PPD file on the system.
>>> This
>>> path is determined by the combination of the basename of the
>>> specified
>>> PPD file, the label, and the Manufacturer name in PPD file (i.e.,
>>> the destination path will be
>>> /var/lp/ppd/<label>/<Manufacturer>/<ppd_file>.
>>>
>>>
>>> printmgr Modifications
>>> ----------------------
>>> Since the location of the ppdcache file used by the printmgr will be
>>> moved from /usr/lib/lp/model/ppd/ppdcache to /var/lp/ppd/ppdcache,
>>> the printmgr will be updated to get it's PPD file information from
>>> this new location.
>>>
>>> The ability to display label information will be added in the printmgr
>>> to eliminate the possibility of having seemingly duplicate entries
>>> for the
>>> Printer Driver field when adding or modifying a printer. This label
>>> will
>>> be displayed along with the printer driver. For example, if multiple
>>> entries exist under the same Manufacturer but different labels, i.e.,
>>> the a Brother DCP-1200 printer model, then the basename of the label
>>> within
>>> parenthesis will be prepended to the Printer Driver field:
>>> (foomatic) Foomatic/hl1250 (recommended)
>>> (Photo) Foomatic/hl1250 (recommended)
>>>
>>
>> 1. Will there be a GUI tool to do the functionality of ppdmgr? Maybe
>> it could be part of printmgr.
>
>
> There could be. That's something we want to think about for the
> future. Do we supply a new GUI, or just add on to the printmgr. I
> could see a tool (ppdsurfer) which would go out and surf the known
> resources for a PPD file to match a specific printer.
I personally would prefer to see it as part of printmgr, so the admin
user can do it all from one place.
>
> For now though, this project is just to allow a user to add a PPD file,
> and have it reflected in the golden ppdcache file.
>
>>
>> 2. When is the printmgr going to be updated so that a given print q's
>> ppd file options can be changed, eg. paper size A4, etc.? The CUPS web
>> admin tool can do this.
>
>
> This is a project Wendy is currently looking at.
I guess a lot of people have been waiting for this feature :-)
>
>>
>> >
>>
>>> In addition, the help application documentation will be updated.
>>>
>>> DOCUMENTATION
>>> The following documentation will be updated to reflect the changes
>>> associated
>>> with this project:
>>> lpadmin(1M)
>>> Advanced system administration guide
>>>
>>> The following man page will be added for the ppdmgr:
>>> ppdmgr(1M)
>>>
>>
>> As a said all minor and wit-picking stuff, so it looks good to me.
>> Hope that helps
>> Paul :-)
>
>
> Phew. Hope I didn't miss responding to any of your comments! Sun has a
> mandatory shutdown the week of July 4th, so this alias might go quiet.
> That said, I plan on spending some time catching up on this project, so
> will most likely be around anyways.
>
> Thank you again Paul! It definitely helps.
That's okay
Paul
