[cups.development] Deleting printers that have no backend

Johannes Meixner jsmeix at suse.de
Thu Sep 1 08:37:34 PDT 2005


Hello,

On Aug 31 Jim Fehlig wrote (shortened):

> I have encountered configurations where it is possible
> to have printers installed with no corresponding backend
> to communicate with the target device.  Details can be
> provided at how I arrived at such a configuration, but
> don't believe it is terribly relevant.

Those details are in fact "terribly relevant" - see below ;-)

> I would like to get the community's thoughts on providing
> a patch that would delete printers for which there is no
> corresponding backend to service the queue.

[...]

> Well, we got ourselves in the predicament :-)  We have two RPMs that provide
> different functionality.  These RPMs target clients and are delivered from a
> server.  The network administrator selects (on the server) which RPM she wants
> made available to her clients.  The RPMs have different names and obsolete
> each other.
> 
> If RPM A is installed on a client, we can handle removing any installed
> printers using our backend when RPM A is removed.  However, if the network
> administrator changes her environment to use RPM B we run into trouble.

This shows that you don't have a CUPS poblem but a RPM problem.

> RPM passes in a value to the first argument of %pre, %post, %prerun, and
> %postrun scripts that represents the instances of this RPM which will still be
> installed after the said RPM operation is complete.  So if the argument's
> value is 0, there will be no instances of this RPM installed after the action
> is complete (removal of the RPM).  If the value is > 0, the action is an
> upgrade.  However, an upgrade action assumes the RPM that is replacing the
> installed RPM has the _same_ name, which is not the case since our RPMs are
> named A and B.  RPM considers these to be two completely different RPMs even
> though they are made to "obsolete" each other.  So when "upgrading" from RPM A
> to B we nuke printers that are using our backend in a %postrun script since we
> do not have correct information in the first argument to the script (i.e. it's
> value is 0).
> 
> We will have to come up with a hack outside of the RPM framework to determine
> if the "upgrade" I have described is occurring and subsequently leave the
> printers installed.

If there is a problem in the RPM framework it must be solved
in the RPM framework because the RPM problem actually does not 
depend on CUPS. 
It will happen exactly the same for any other software system
where two RPMs obsolete each other.

Perhaps the following may lead to a solution:

What I have in mind is that in case of a single package update
RPM does first install the files of the new package and then
it removes the files of the old package.
See for example the file "triggers" in the RPM documentation:
--------------------------------------------------------------------
the order in which scripts are executed on a single package upgrade:

  new-%pre      for new version of package being installed
  ...           (all new files are installed)
  new-%post     for new version of package being installed

  any-%triggerin (%triggerin from other packages
                  set off by new install)
  new-%triggerin
  old-%triggerun
  any-%triggerun (%triggerun from other packages
                  set off by old uninstall)

  old-%preun    for old version of package being removed
  ...           (all old files are removed)
  old-%postun   for old version of package being removed

  old-%triggerpostun
  any-%triggerpostun (%triggerpostun from other packages
                      set off by old uninstall)
--------------------------------------------------------------------

If A and B obsolete each other and A is installed but now the admin
installs B then I hope (I didn't test it) that in this case RPM also
first installs the files of B and then removes the files of A
(i.e. I hope that RPM does it like an update of a single package).

This way when running a uninstall script of A the new files of B
may be already present so that this way it may be possible to
distinguish the case when A is simply removed or when A is to be
removed because it is obsoleted by an installation of B.


Kind Regards,
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/





More information about the cups mailing list