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

Re: Proposal: handle dpkg as a non-Debian package

Wichert Akkerman <wichert@cs.leidenuniv.nl> writes:

> Excellent plan, but right now the diff is huge since dpkg-iwj doesn't
> have gettext-support yet.

Ugh, yes that would make for a really huge diff.  I think we could at
least get Ian to add _() around every string but not actually do any
gettext stuff.  He would just do
#define _(a) a
That is the bulk of the diff.

Ian, would you let somebody apply a patch to iwj-cvs which fixes just
that and only that?

> It would probably be very helpful if dpkg-iwj became a (pseudo)package
> that the BTS can handle as well: that makes it easier to forward bugs to
> upstream (simply reassign :).

Yes, that's a simple enough mechanism.  Every time we fix a bug in
dpkg, we forward the bug to dpkg-iwj and attach the diff to the bug.
Ian than then review the fixes and applyt them or better fixes or
whatever.  Of course, Ian, you're welcome to fix dpkg bugs in dpkg-iwj
as well. ;-)

> > We could use the vendor branch facility to push dpkg-iwj into dpkg.
> I'm afraid I'm not familiar enough with CVS to be able to use that,
> someone will have to help me a bit here initially..

I can set it up for you.  Basically the concept is that you have some
diffs to some upstream code, and you want to keep those diffs when a
new version of the upstream code comes along.  You check your code in
on the trunk and have a branch where you check in the main code.

So far it's just like a regular branch.  The difference is that the
HEAD of the code will move automatically on a file-by-file basis from
the vendor branch to the main trunk depending on if you have made
diffs to that file or not.

> I'ld love to see things like dpkg-source having a seperate maintainer
> btw.

I think a lot more people would be willing to hack on it if there was
an up-to-date cvs tree and assurance that their patches would be

So, since two people agree with me, that's enough for me, so let's go
ahead and do it.  Here's what we have to do:

1. Stop doing NMUs that are not built out of the dpkg cvs tree on

2. Get the cvs dpkg tree up to date.  I can check in the latest NMU
and the latest dpkg-iwj and tag them as cvs-buildpackage suggests.

3. Clean up the bug list by adding a dpkg-iwj pseudopackage, and
forwarding bugs, etc.

So I'll get started on getting the cvs dpkg tree up to date.


Reply to: