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

Re: [Gimp-print-devel] Debian packaging of gutenprint



   From: "Roger Leigh" <rleigh@codelibre.net>
   Date: Sat, 1 Nov 2008 17:20:04 +0000

   On Thu, Oct 30, 2008 at 08:55:14PM -0400, Robert Krawitz wrote:
   >    From: "Roger Leigh" <rleigh@codelibre.net>
   >    Date: Fri, 31 Oct 2008 00:41:46 +0000
   >=20
   >    On Thu, Oct 30, 2008 at 07:44:33PM -0400, Robert Krawitz wrote:
   >    >    From: "Roger Leigh" <rleigh@codelibre.net>
   >    >    Date: Thu, 30 Oct 2008 22:48:43 +0000
   >=20
   >    > If you (or any other distribution) wants to do this, I'd suggest usi=
   ng
   >    > EXTRA_VERSION of "-debian_1" or the like so that we know that it's a
   >    > version with non-standard changes.  Also, make sure you have someone
   >    > subscribed to the list, and preferably with a Sourceforge account th=
   at
   >    > we can assign bugs to (if someone's using a non-standard release, I
   >    > would redirect all bugs against that release to the distribution
   >    > maintainer for initial triage).
   >=20
   >    For Debian at least, we would most likely only ever pull in
   >    specific changesets from upstream in order to fix a particular bug,
   >    that is we would never introduce code not already committed into
   >    upstream CVS.
   >=20
   > The problem with that is that you'll still wind up with a different
   > source base than the particular upstream named release.  My preference
   > would be for you to pull the entire new release, or if that's not
   > practical to otherwise identify the release as being unofficial.

   How would you prefer this to be done?  We already append a Debian
   version to the release version, e.g. 5.2.1 is currently 5.2.1-2
   (the second Debian release).  These changes are always applied to
   the original sources as patches in a .diff.gz addition to the
   original release tarball.

Ideally, something like 5.2.1-debian1 or the like.  I can't insist on
it, but it will make everyone's life easier.  I'm aware that
distributions aren't doing this as a matter of course, but...

   >    Currently, the exception is a single one-line difference we patch in:

   > I don't think that this should be applied, for two reasons:
   >=20
   > 1) GIMP 2.4/2.6 will use print-gutenprint.c unless you explicitly pass
   >    --without-gimp2-as-gutenprint on the command line, which is not
   >    standard.  print-print.c is specifically intended for use with GIMP
   >    2.0/2.2.  Normally with GIMP 2.4+ the option is named Print with
   >    Gutenprint...
   >=20
   > 2) The built-in GNOME-Print based plugin in GIMP appears to be
   >    File/Print, not File/Send/Print.  Unless the GIMP folks disagree, I
   >    think we should use the same layout.

   OK, that sounds reasonable, so I've dropped this patch.  We weren't
   compiling it anyway.

   I've now updated the Debian git repository to store the upstream patches
   on a patches branch:

   http://git.debian.org/?p=3Dcollab-maint/gutenprint.git;a=3Dshortlog;h=3Dref=
   s/heads/patches

   This is then used to construct a quilt patch series from the deltas
   between this branch and the upstream branch.  Currently, this
   contains just one patch, for the VPATH build fix I committed a
   couple of weeks back (we can't build without this).  We'll split
   that single patch up into a set of single changes to separate the
   autotools regenerated files from the actual changes.

Quilt patch?

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


Reply to: