Bug 76477 - system default printer can be set in two different, conflicting places
Summary: system default printer can be set in two different, conflicting places
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cups
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-22 09:17 UTC by Robert P. J. Day
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-10-22 09:17:20 UTC
Embargoed:


Attachments (Terms of Use)

Description Robert P. J. Day 2002-10-22 09:17:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
  according to the docs, CUPS can have a system default printer
that can be seen by running "lpstat -d".

  however, there are two ways to set this system-wide value.
the first, through "lpadmin -d" puts the default value in
/etc/cups/printers.conf.

  the second, by running "lpoptions -d" as root, puts the
default printer name in /etc/cups/lpoptions, and this value
overrides the one in printers.conf.

  this is confusing since root can (allegedly) set a value
using "lpadmin", yet this value is ignored if a value has
already been set via lpoptions.

  as i've heard it, this is by design.  it's very confusing.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1."# lpadmin -d printer1" to set a default printer
2."# lpoptions -d printer2" to set a different default printer
3."lpstat -d" to see the (alleged) default printer, which will
  always allow lpoptions to take precedence despite the docs
  for lpadmin which simply say that you're setting the 
  "default" printer
	

Actual Results:    lpoptions value always takes precedence

Expected Results:  it would be nice if CUPS understood the concept of a single
default printer.

Additional info:

Comment 1 Tim Waugh 2002-10-22 09:23:10 UTC
As I said, I won't change this since it is designed to work the way it does. 
This is something to take up with the upstream developers.


Note You need to log in before you can comment on or make changes to this bug.