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

Re: dpkg-source's future and relation with VCS

On Tue, 12 Feb 2008, Russ Allbery wrote:
> 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.

This doesn't work well. Upstream tarballs inside a single .tar.gz
requires reupload of all the upstream sources for every revision.

(That's also one of the weak point of the VCS based format as implemented

The plugin architecture shouldn't assume a single tarball, it should
receive as input the list of files contained in the .dsc and it should be
able to use every file. This should be easy to do once the code in
dpkg-source is factored out.

> > 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.

This is why I believe a debian/sources.rules file makes sense. For simple
cases, one would just have to include standard rules (say
/usr/share/dpkg-dev/vcs/git.make), some special cases could be handled by
variables and very complex cases could have some custom logic not provided
by dpkg-dev.

Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :

Reply to: