Bug 111890 - Applications which assume default printer is called lp fail
Applications which assume default printer is called lp fail
Product: Fedora
Classification: Fedora
Component: redhat-config-printer (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2003-12-11 04:41 EST by Hans de Goede
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-11 05:09:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2003-12-11 04:41:14 EST
It's a few days ago so I can't remember teh exact application but the
problem is generic:

Applications which assume the default printer is called lp fail,
unless you call your default printer lp.

Suggested fix:

Let redhat-config-printer add an alias called lp for the default printer.
Comment 1 Tim Waugh 2003-12-11 05:09:31 EST
There is no need for any application to assume that name.
Comment 2 Hans de Goede 2003-12-11 05:28:08 EST

But historically some applications do. Back in the days of printtool &
lpd, printtool used to add the lp alias for the default printer.

I wish I could remember which app I was using when I hit this :|

Anyways its your call.
Comment 3 Tim Waugh 2003-12-11 05:40:52 EST
For some situations it just plain doesn't make sense.

1. Default queues can be user-specific anyway, using lpoptions.

2. Default queues can be remote, not even defined locally but just
referenced in /etc/cups/lpoptions.

3. What if the queue 'lp' is defined by some other means, for example
by the CUPS web interface or from the command line, before
redhat-config-printer writes out its configuration?

4. What if 'lp' is a remote queue?

5. What happens when several different print servers export a
particular queue?  Each would also export 'lp' (since browsing cannot
be limited to particular queues) and that could cause all manner of

6. 'the default queue' can change over the time, and in particular
during times when the redhat-config-printer backend will certainly not
get run -- and so the 'lp' default tracker queue would not be able to
track properly and would point to the wrong queue.

7. Since 'the default queue' has several meanings already (user's
preference, lpoptions default, DefaultPrinter tag in
/etc/cups/cupsd.conf, default is remote and there are no local queues,
etc.) adding yet another meaning doesn't seem the right direction.

I think it's something best fixed in the applications.

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