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

Re: intend-to-implement: script to obtain Debian Source

On Sun, 27 Mar 2005, Lars Wirzenius wrote:

> su, 2005-03-27 kello 09:01 +0200, George Danchev kirjoitti:
> > I second suggestion given at #250202 and like to see "unpacked" and "patched"
> > targets to hit Policy 4.8.
> I hear that Adam Heath (doogie for those on IRC) has been working on a
> new source package format that will make tarball-within-tarball sources
> obsolete and has native support for multiple patches and cures for other
> ailments. If this works, and I suspect it will, then "unpack" and
> "patch" targets will also be obsolete. Personally, I think this will be
> a good thing.

The new toolset(tentatively called dbs-ng while I'm developing it) supports
what I call pre-patched source.

dpkg-source -x foo.dsc gives a source tree that is immediately ready for
editting and building.  No need to apply patches by running something inside

If you modify a file, then dpkg-source -b the dir, it'll be included in the
standard diff.gz, just like a standard package.

However, if you want the patch to be maintained separately, dbs-ng -d
foo.patch will product a file called foo.patch in $PWD that contains the
change you have done.  You can then move that into debian/patches.

Another major feature is patch dependencies.  No longer do you have to prefix
your patch names with numbers, to get the ordering right.  Now, you just list
the other patches you depend on, and they will be applied in the correct
order.  Additionally, as a way to weed out other problems, any patches that
are leafs(ie, don't depend on anything) are applied in a random order.

Also, all patches now have a leading dpkg control paragraph; this contains the
Depends line, Description, Flags, and other fields.

The tool also supports mailing patch sets to email addresses, including
diffstat output, etc.

The initial version is in perl, and is done.  I'm working on rewriting it in
C, however, before I release it.

ps: I do have a second perl version that *does* support changes to binary
files, permissions, file types, renames, etc that will be merged into the C
version.  This new diff format is encoded in a format that is capable of being
run as a *shell script*, so that you don't need the advanced toolset on the
system to apply the series of changes(useful for bootstrapping).

Reply to: