Re: Orphaning of gutenprint
On Tue, Feb 14, 2012 at 02:03:25AM +0100, Till Kamppeter wrote:
> I am about to package 5.2.8rc1 for Ubuntu Precise before Feature
> Feeze on Thursday.
>
> I have looked through the Delta and most of the differences can be dropped:
OK.
> - 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.
If you feel this is useful for Ubuntu users, that's fine. If the
simplified PPDs are user-friendlier, it might be worth retaining
them. While I kept the "full" PPDs in Debian, I'm not aware of
many people using them; I would guess that only a tiny percentage
of users tweak all the knobs.
> - 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?
It would help to know who the intended users of this package are.
What can use these PPDs other than CUPS? Does this package
provide benefits which the native CUPS driver does not?
There's no need for the CUPS and ijsgutenprint packages to conflict
here, given that they serve different needs and can be used
independently.
> - 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.
I think I mentioned this in an earlier mail, but I'll reiterate it:
have these been submitted upstream? They do need to be upstream
before it makes sense to include, given that they are not critical
bugfixes. Depending only on perl-base might be useful, but it's
not a reason to diverge from upstream. Once these changes are
upstream, then we can make this change.
> - 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)?
We do need this option; it should be added back. I thought it
was added by dh_auto_configure, but apparently not. Possibly
dependent on the dh compat level. I just checked with 9, and
it's not added.
> - 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.
We could drop this file; nothing uses it AFAICT, so it's just taking
up space.
> - 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.
The above options are presumably Ubuntu-only decisions, given that
this was never provided or supported by Debian. As I mentioned at
the top, I'm not sure if there are any significant use cases for
this setup which the native CUPS driver does not provide. If there
are not, then migration may be useful given that it will greatly
simplify things. As I said above, I don't think conflicts are
appropriate here, so I don't think (1) is a good idea. 2—4 are all
OK, depending upon whether it's a useful feature to keep. If it's
not useful to keep, then (2) would be the best, I think.
Regards,
Roger
--
.''`. 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: