Re: Refactoring action 1 - Renaming printer driver packages - Status update
Roger Leigh wrote:
> On Thu, Nov 03, 2011 at 12:32:57PM -0400, Till Kamppeter wrote:
>> On 11/03/2011 11:16 AM, Didier Raboud wrote:
>> >Under my current understanding and given the fact that many of the
>> >already- named printer-driver-* are in fact cups-specific, I would only:
>> >* rename cups-driver-gutenprint to printer-driver-gutenprint,
>> >* include printer-driver-gutenprint to printer-driver-all's list of
>> >and leave the others as they currently are. Rationale being that cups-
>> >driver-gutenprint, from the descriptions of the packages, is sufficent
>> >for cups to be able to print to the supported printers.
> This sounds fine; I'll do this for the next upload.
>> So I suggest the following:
>> cups-driver-gutenprint -> printer-driver-gutenprint-cups
>> ijsgutenprint-ppds -> printer-driver-gutenprint-ijs
> Do we want the -cups suffix for all drivers, or is this contrary to the
> general naming scheme? If we do, we might want some standardised
> suffixes as well.
As most (if not all) printer drivers are made for cups (either by upstream
that links againsts libcupsdriver or by Debian that ships .drv files only),
and as we have not heard about any efforts from other printer spoolers
maintainers, I would oppose to have -cups postfixes by default.
>> Note that perhaps ijsgutenprint-ppds did not make it yet into
>> Debian. In this case the Ubuntu package needs to get merged back
>> into the Debian package.
> This is the first time I've heard of this package. Why was this change
> not made in the Debian packaging first, and not discussed on this list?
> I've mentioned this repeatedly in the past: I would like to see such
> changes made in Debian first, rather than incompatible changes being
> made in Ubuntu. I don't want to feel obliged to deal with the
> consequences of poor or ill-considered changes in Ubuntu, *particularly*
> when it comes to package interdependencies which make things
> unnecessarily painful.
> Is there any point in providing the foomatic data if pre-generated
> PPDs are being provided? I thought the idea was that foomatic would
> generate them on the fly? Is the foomatic data in general still
> serving a useful purpose? Who or what is the intended consumer of
> this data, and could it be generated dynamically?
> Looking at the popcon data, the number of installations of
> ijsgutenprint and foomatic-db-gutenprint has dropped dramatically in
> the last year, and actual usage is tiny, when compared with
> cups-driver-gutenprint. A similar trend is seen for some of the
> foomatic packages. If other spoolers could be patched to use the
> CUPS filters automatically, I think it would be worth considering
> dropping some of this great complexity, beginning with leaf packages
> such as ijsgutenprint.
My point of view on the matter is that we shouldn't drop packages that might
be useful to others, such as ijsgutenprint. Let's just do one improvement at
a time; and for this "action 1", what we need is one printer-driver-*
package that installs what is necessary for cups to be able to print to the
printers supported by the given driver.
So, in short, I now consider (and it seems I changed my mind… :-> ) that the
printer-driver-* namespace is there for "printer drivers that work with
cups". If there is a way to make those less cups-specific, then people
should chime in and "show us the code". We should not "allow" non-cups
packages under the printer-driver-* namespace, at least not currently.