On Sun, Nov 02, 2008 at 05:50:50PM -0500, Robert Krawitz wrote: > 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 > > 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... For Debian, the version number consists of three parts: epoch:upstream-debian epoch is a single integer, used to correct major screwups in versioning (we don't use it for gutenprint, since we haven't botched anything) upstream is the release version from the upstream release. Because we distribute the upstream tarball bit-for-bit identical to the official release (with the minor detail that we gzip it rather than bzip2, at least until bzip2 is allowed in the next month or two), it has exactly the same number. The exception is when we need to remove stuff e.g. for legal reasons, in which case it has a suffix to make the alteration noticeable. If we were to modify the release directly, we would alter the version number in the tarball name to indicate this fact. debian is the version of the debian release. Normally just a signed integer; names such as lenny1 are used for updates to stable releases. We don't usually put the name "debian" in the version because it's implicit. It's currently taken as a given that the Debian version may or may not include patches to the source distribution. These are always clearly visible in the .diff.gz part of the source package. Normally there are no patches; if we pick up a changeset from an upcoming point release to fix a critical bug, it will be dropped as soon as that release is packaged. > > 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? http://savannah.nongnu.org/projects/quilt http://www.suse.de/~agruen/quilt.pdf It's used to maintain a whole set of patches, including applying and deapplying them. We generate the patch series from the above URL using git: git format-patch -o <dir> patches ^upstream which generates a separate patch for each commit on the patches branch from its branch point on the upstream branch to the head. The branch itself is rebased against the current upstream release using "git rebase --interactive" to add/remove/split/combine/edit/reorder commits. I just discovered this feature of git this weekend--it's pretty cool. If you apply http://ftp.debian.org/pool/main/g/gutenprint/gutenprint_5.2.1-2.diff.gz to the 5.2.1 release, you'll see the quilt patch series in debian/patches. You can then apply and deapply the series with QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null push -a QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R 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.
Attachment:
signature.asc
Description: Digital signature