[cups.development] Re: [Gimp-print-devel] Can't use EpsonPictureMate with GutenPrint 5.0.0rc2

[Michael Sweet]

Klaus Singvogel wrote:
> Hi.
> I'm currently not subscribed to gimp-print-devel (and others maybe
> neither). Therefore I'm responding to cups-dev too. :-)
> 
> Michael Sweet wrote:
>>> Yep, the device should be usb:/dev/usb/lp0, but it's replaced by this one.
>> Actually, no, the "usb://EPSON/PictureMate" URI is the correct one, the
>> filename-based URIs are deprecated and are no longer allowed in CUPS
>> 1.2 (the filename will change randomly if you have more than one printer
>> attached...)
> 
> Well, I'm a bit unhappy with this decision.

Learn to live with it - we have spent several years dealing with
users with multiple USB printers that are randomly reassigned.  It
is simply not reliable to use hardcoded device filenames.

> You're right, the printer taken as /dev/usb/lp0 is chosen randomly.
> But there exist lots of documents where /dev/usb/lp0 is named. If you
> no longer allow it, CUPS users might run into deeper problems, if they
> just upgrade their printing system from 1.1.x to 1.2.x, and if its no
> longer working. This should not happen.

Since we have not used hardcoded filenames on Linux since CUPS 1.1.15
(which was released in June 2002, 3.5 years ago), we are not going to
propagate this problem with the USB backend into CUPS 1.2.

If this is a real problem for *your* customers, then *you* need to
deal with it in your installer.

> Even I'm not happy to say this, but Microsoft is doing a good example
> how it should be done: warn the user in first major upgrade, and
> disallow it in the next major upgrade. Therefore I'm asking you, if we
> can see a warning message in the "State:" field of the printer, or
> somewhere else, instead, but allow if for some time?

No, it has been 3.5 years since the last release that used the
raw device filenames.  We've told everyone what the proper URIs
will look like as advertised by CUPS, and Linux distributions in
general have ignored the information and APIs we supply.

> A rejection of the configuration command, if any such outdated URI is
> used, is acceptable either. But then there should be a good hint given
> to the user either, what should be used instead. The rejection should
> also been done by the front-end and not by the daemon.

You'll get an error message in the error_log, as well as a printer
state message saying "bad URI", and with the default behavior the
queue will stop since the backend failed.

> A support of old configuration should not been dropped in such a cruel
> way. At least, if the version of CUPS only changes only from in a minor
> version number. :-)

A CUPS minor version number, especially with CUPS 1.2, is the
equivalent of a major release.  The only reason we are not calling
this CUPS 2.0 is because we are not breaking API compatibility,
redesigning the scheduler, or doing other things that would
constitute a major rewrite of the code.

In the future, you'll see ONLY bug fixes in the patch releases and
new features in the minor releases.  You'll see more frequent minor
releases with fewer changes (1.2 has been a LONG time coming), and
we'll do a few patch releases as needed, but only to fix bugs (no
new features in patch releases like we did in 1.1.x!)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com