I have looked through the Delta and most of the differences can be dropped:
- debian/rules: Include the simplified CUPS Raster PPDs of
Gutenprint by an explicit "./configure" option.
Will drop that and add a .ppd-updater file to auto-migrate to
the full PPDs.
- debian/control, debian/rules, debian/ijsgutenprint-ppds.install,
debian/cups-driver-gutenprint.install, debian/ijsgutenprint-
ppds.postinst:
Added the binary package ijsgutenprint-ppds: This package
contains all PPDs which can be generated from the Foomatic XML
database for ijsgutenprint in one compressed pyppd archive. This
takes much less disk space than the XML database (1.1 MB vs. 102
MB) and makes access (listing all PPDs, extracting the needed
PPD) also significantly faster.
For CUPS users this package makes a lot of sense as 102 MB of
Foomatic XMLs are replaced by 1.1 MB of compressed PPDs, but
CUPS users should use the CUPS Raster driver. So I could drop
this additional 1.1 MB (and 2 hours build time) binary package
and migrate CUPS/ijsgutenprint users to the CUPS Raster driver
via a .ppd-updater file (and perhaps even make CUPS and
ijsgutenprint conflict). WDYT?
- debian/patches/generic-large-format-printers.patch: Use "Large
Format" instead of "LF" in the names of the Generic PCL printers,
this way users understand better what the difference between the
entries is.
I will drop it as it is included in 5.2.8.
- debian/patches/no-data-dumper-needed.patch: Data::Dumper is
imported,
but never actually used, so drop that.
- debian/patches/upgrade-getopt.patch: Replace Getopt::Std by
configuring Getopt::Long to run in a mode compatible with
Getopt::Std
- debian/control: Dependency on perl is no longer necessary -
Data::Dumper and Getopt::Std were the last modules being used
that aren't in perl-base.
These three we should overtake into Debian as they eliminate
the dpendency on the full Perl package and allow to depend on
perl-base.
- debian/rules: Build with "--enable-nls" in the "./configure"
command line.
I remember that it was for some part of the I18n. Is this
really needed (for example for globalized PPDS)?
- debian/local/apport-hook.py, debian/rules,
debian/cups-driver-gutenprint.install: Added apport hook.
I will proceed as in the CUPS package here.
- debian/cups-driver-gutenprint.postinst: Make failures of the
update for the PPD files of existing print queues for the CUPS
Raster driver non-fatal
Generally a good idea, but due to the need of migrating
simplified PPDs and ijsgutenprint PPDs to full CUPS Raster PPDs
we need a .ppd-updater file for the CUPS Raster driver anyway
and so we can remove the PPD updating from .postinst.
- debian/cups-driver-gutenprint.install: don't install
samples/profile.jpg
Having a delta for eliminating only one file is overkill, will
drop this difference.
- debian/patches/10_cups_modeldir.patch: place ppd files in
/usr/share/ppd
This I will drop, as the whole Gutenprint package does not ship
physical PPDs, independent whether we build the
ijsgutenprint-ppds binary package or not.
- debian/control: Added transitional cupsys-driver-gutenprint
package,
easing the transition from hardy. Versioned Conflicts/Replaces.
I will drop this, Hardy is OOOOLD!
- debian/foomatic-db-gutenprint.postinst: automatically update the
PPD files of existing CUPS queues which use the IJS driver.
Automatic PPD update is a good idea, only to be dropped if we
really let ijsgutenprint and CUPS conflict.
WDYT about this way to handle the differences? And how should we proceed
with the relationship between ijsgutenprint and CUPS:
1. (Most radical): Let ijsgutenprint and CUPS conflict and migrate IJS users to Raster via .ppd-updater file
2. Only remove ijsgutenprint-ppds and migrate IJS users to Raster via .ppd-updater file
3. Keep ijsgutenprint-ppds and migrate IJS users to Raster via .ppd-updater file
4. Keep ijsgutenprint-ppds and do not migrate IJS users. Till On 01/06/2012 02:44 PM, Roger Leigh wrote:
On Thu, Jan 05, 2012 at 10:26:03AM +0100, Didier Raboud wrote:just a short notice to summarize my position: I am willing to co-maintain gutenprint, either with Roger or with Till, even better with both (more to have it maintained than by personal interest). As Roger, I don't think blindly accepting all Ubuntu changes in Debian is good for either distros but I certainly think that having a common source package and packaging repository can help. It is possible to accomodate many "derivative-specific" (such as apport hooks e.g.) changes in a common source package (with dpkg-vendor snippets e.g.) and I don't see why we shouldn't.I am perfectly happy with either or both of us as co-maintainers. I should add that my criticisms of the Ubuntu package were only to illustrate why I think a wholesale adoption of the Ubuntu packaging would be a bad thing. I'm sure that having a common repo would be good, and Ubuntu-specific bits can certainly be special-cased or go on a different branch. Releasing off a different branch would probably be the best way, i.e. having an "ubuntu" branch which can be synched with the debian branch. When I've looked through the Ubuntu delta in the past, I've gone through it line-by-line to see what Debian should pick up (or not). Really, the same process needs to happen the other way also, i.e. to justify why a difference exists, and if it should continue. Some such as the simplified PPDs are not appropriate for Debian, others may be.5.2.7-2/configure 5.2.7-2/configure.ac Both obsolete and were reverted in Debian.Those are put in by debian/patches/cups_modeldir.patch, unneeded if no PPD files are shipped, right ?Yes.5.2.7-2/debian/foomatic-db-gutenprint.ppd-updater Needed?"ppd-updater" files trigger a cups postinst call at installation time, allowing cups to update its PPD-based queues, avoiding the need to duplicate that functionality in all printer driver packages (see cups postinst). Packages using that functionality should probably Break: cups (<< 1.5.0-3~).Right. This would probably be worth including, as would the other one for the CUPS-native driver. If it would obsolete cups-genppdupdate, then so much the better. I am unsure why such as useful addition is not included upstream. The existing cups-genppdupdate was developed by and for Debian, but was upstreamed from the start. If it works for all CUPS installations (i.e. is not Debian- and/or Ubuntu-specific), then it should go upsteam. Till, is there any reason why this has not happened? It could go into 5.2.8. Regards, Roger