[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Refactoring action 1 - Renaming printer driver packages - Status update

On Thu, Nov 03, 2011 at 12:32:57PM -0400, Till Kamppeter wrote:
> On 11/03/2011 11:16 AM, Didier Raboud wrote:
> >Roger Leigh wrote:
> >>
> >>How would you like gutenprint to rename its packages to work with
> >>the new system?  In terms of user-visible packages (excluding libs)
> >>we have
> >(fwiw, I don't know much about gutenprint, so… Maybe Till has a better
> >opinion on the matter.)
> >
> >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
> >recommends,
> >
> >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.

> All other binary packages do not get renamed.
> 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.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Reply to: