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.
There is no need for any application to assume that name.
True, 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.
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 confusion. 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.