Re: dpkg-source's future and relation with VCS
Anthony Towns <aj@azure.humbug.org.au> writes:
> - Raphael's looking at enhancing the wig&pen format (eg, adding
> a file explicitly listing patches to apply), and making
> dpkg-source able to generate a wig&pen format package; Russ may
> be looking at automating the process of generating wig&pen format
> packages for packages maintained using quilt
So, I slept on this, and it really doesn't look hard. It doesn't look
like wig&pen, but I'm pretty sure you can easily programmatically convert
from this format to wig&pen and vice versa. (Joey's plugin infrastructure
is *wonderfully* easy to understand.)
Basically, the way to do this is to do the dbs thing, I think. The
structure of the .tar.gz file would be:
- All content in the .tar.gz file is in a debian subdirectory as packed.
- debian/patches contains a quilt series file and set of patches.
- debian/upstream contains one or more .tar.gz or .tar.bz2 files plus a
series file that specifies the order of unpack.
On unpack, you:
* Extract the tar.gz, which gives you an almost empty directory with only
a debian subdirectory.
* For each upstream tar file in debian/upstream/series, extract that tar
file into a working tmp directory. (This will require messing with how
the tar files extract since they may use different base directories,
but that's a solved problem from other tools.) Files found in later
tar files overwrite files found in earlier tar files.
* Lift the contents of the tmeporary directory up one level so that the
result looks like a regular Debian package looks today. Making
everyone work in a subdirectory requires unnecessarily annoying
fiddling in debian/rules.
* Run quilt push -a or the moral equivalent with QUILT_PATCHES pointing
to debian/patches.
To create such a package from a quilt working tree, you:
* Check to see if the complete patch set is still applied (using quilt
applied and checking against debian/patches/series). If a different
set of patches are applied than are listed in series, you assume that
the person working in the source tree knows how to use quilt and you
run quilt pop -a to get a clean tree and error out if quilt pop -a
fails.
If all the patches are applied, the person may not have paid any
attention to quilt, and you need to recover any additional changes. To
do that:
- Move all non-debian files down one level into a temporary working
directory.
- Create a second temporary working directory by unpacking the
upstream source tarballs and then doing a quilt push -a in that
second directory roughly as described above.
- diff -r between the directories. If the diff is empty, there are no
changes not captured as patches. If the diff is non-empty, save
that diff in debian/patches with a unique name and add it to the end
of the series file.
* Remove everything other than the debian directory.
* Make a tar file of the result.
So, what you get with this package format is the debian directory put
directly in the tarball (so you can add binary files there, etc.), a
debian/upstream directory that can contain as many overlapping upstream
tar files as needed, and a debian/patches directory with a series file
recording all the patches. Transformation into the wig&pen format should
be trivial. The patches can be generated by appending increasing numbers
to the patch files based on their order in the series file.
> So way back in the day, I did try writing a conversion tool from darcs
> to wig&pen and back -- the problems I had were that it was kludgy to
> manage because of the way the patches weren't separated from everything
> else (eg, there's nothing stopping a Wig&Pen patch from patching an
> earlier/later Wig&Pen patch) and it was really slow to actually replay
> through the darcs history to generate the patches.
This is definitely the hard part. Going from a repository to wig&pen
without any hints or additional information about how the repository is
working is going to be either really hard or fairly unsatisfying. It gets
much easier if you can give the conversion hints (this is my debian
branch, these are all of my feature branches, each feature branch is a
separate patch, here's the order in which the feature branches are merged,
that sort of thing). Some of those hints may be extractable from the VCS,
depending on the VCS.
>> If tailor works now as a many-to-many conversion tool, that would
>> address my concern even better.
> Uh, you don't know about tailor? http://progetti.arstecnica.it/tailor
I know about it. I just haven't used it in anger and I don't know how
well it tackles these problems. A quick review of its documentation gave
me the impression that it's fairly fiddly, but that's only a first
impression and I don't want to make any judgement until I'd had time to
actually try it (or someone else tells me that it's really easy).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: