Re: Proposal new source archive format
>>>>> "Ben" == Ben Collins <bcollins@debian.org> writes:
Ben> On Mon, May 01, 2000 at 02:56:08PM +0200, Wichert Akkerman wrote:
>> Previously Joey Hess wrote:
>> > Er, you have to list _all_ files, upstream or not. Notice that .diff.gz
>> > is currently listed in .dsc files.
>>
>> The patch-files are inside the debian diff, which is also listed in the
>> .dsc but is special.
Ben> So we are back to the diff of a diff? Why not make the debian/ a .tar.gz
Ben> for easier change and perusal? If all of the patches are seperate from the
Ben> original source, why do we need to use diff.gz at all for our debian
Ben> stuff?
Ben> it could still be a special .tar.gz. It could even be forced to be named
Ben> pkg-ver-rev-debian.tar.gz (in relation to pkg-ver.orig.tar.gz), and then
Ben> further force the assumption that it contains one directory called
Ben> "debian/" with all of the relevant files/patches in there. Seems like an
Ben> easier plan to me, since you don't need to diff, just tar/untar, and it
Ben> gives the extra added benefit of allowing binary files (gif's, jpeg's
Ben> etc..) to be added by the maintainer (HUGE benefit!).
I like this. No more messing around with base64 or uuencoded graphic
files so they'll end up in the .diff.gz.
It's useful, when working from upstream CVS, to create a local (under
Debian maintainer control) CVS repository of just the
"$pkgname/debian/" directory. You then checkout the upstream module
from their CVS server, and then overlay that with the module stowed
in your own CVS repository. A `M-x cvs-update' in the toplevel of
the program source will get from the upstream repository for most of
it, and from your own CVS for the "debian/" subtree. It works very
well.
A CVS aware `dpkg-cvs-genpatch' could be run to pull out a set (or
maybe several sets, somehow) of diffs against the upstream source and
put them in the "debian/patches/" location, perhaps. Is there a
problem with checking in a diff file to CVS? I never thought of
that... seems like it's probably doable though.
The generated diffs would then be against the upstream repository,
making it easier on them when you forward the patch to their patch
queue and review board.
There should be a control file for the `dpkg-cvs-genpatch' that tells
it what files to group when generating patches, and what to name the
patch file generated.
Vendor tracking should be supported as well. For that, the genpatch
control info ought to be able to tell it to diff between revisions to
generate a patch - to try and keep it so each diff contains only one
logically related set of changes, to ease the upstream task of
merging them into the main codebase.
This is very off the cuff.
Reply to: