[cups.development] Deleting printers that have no backend

[Helge Blischke]

Jim Fehlig wrote:
> 
> Helge Blischke wrote:
> 
> >Jim Fehlig wrote:
> >
> >
> >>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.
> >>
> >>
> >
> >As it's the very first time I hear about an issue like this, I'd be interested on
> >how you did get there ...
> >
> >Helge
> >
> >
> >
> 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.
> 
> 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.
> 
> Hope I have articulated this clearly :-)
> Jim

Why can't you implement a call to rpm causing a complete remove of the 
respective other RPM in your pre(run) scripts? I did similar things with 
the preinstall scripts in Solaris-like packages.

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de