+++ This bug was initially created as a clone of Bug #476220 +++ Description of problem: The spec file for the openoffice.org-core RPM does not flag the file /usr/{lib,lib64}/openoffice.org/share/psprint/psprint.conf as a configuration file. As a result, upgrading the package results in the machine's printer configuration being overwritten. Version-Release number of selected component (if applicable): openoffice.org-core-2.3.0-6.5.4.el5_2 and earlier How reproducible: Always Steps to Reproduce: 1. add a global printer to OOo2 (e.g., using /usr/{lib,lib64}/openoffice.org/program/spadmin as root) 2. upgrade or reinstall the openoffice.org-core RPM Actual results: The new printer is no longer present, since the file /usr/{lib,lib64}/openoffice.org/share/psprint/psprint.conf is replaced with the file from the new RPM. Expected results: The new printer should be preserved. Additional info: This defect also applies to Red Hat Enterprise Linux 4 (cf. Bug #476220).
FWIW It is not recommended to use spadmin to add a printer that OOo alone can use, just use the normal desktop printer adding software. spadmin really only exists for the moment in RHEL to give a way to support fax numbers for printing direct to fax.
Okay, then /usr/{lib,lib64}/openoffice.org/share/psprint/psprint.conf should be marked as a configuration file so that the fax printers defined in that file don't get removed when OpenOffice is updated. At our site we need to add printers via psprint.conf because we cannot use CUPS for printing due to its lack of support for user authentication. (E.g.: the GTK2 CUPS print backend does not work at all when any type of CUPS authentication is enabled; cf. bug #476232.) Conversely, I don't see a downside to marking psprint.conf as a config file in the RPM.
In general I think this is a bad idea to need to modify the OOo config specifically to hackaround a problem, i.e. problems still persist for e.g. evince and the rest of the desktop stack. That said, it doesn't hurt to be able to at least print from OOo.
Yes, needing to modify the OOo config to work around a problem is less than ideal; however, being unable to do so where no better solution exists is worse. psprint.conf is, by its suffix, clearly a configuration file: if the user customizes it (irrespective of whether that customization is recommended or not), it is difficult to understand how destroying these customizations during a package update can be the right thing to do.
checked in for >= 2.3.0-6.11
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1248.html