On mar, 2007-12-11 at 15:43 +0000, Neil Williams wrote:
> On Tue, 11 Dec 2007 08:52:17 -0600
> Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com> wrote:
>
> > On Mon, Dec 10, 2007 at 07:29:39PM +0100, Carlos Martín Nieto wrote:
>
> > > I think the reason Makefile.{am,in} are patched directly is because the
> > > patches are applied too late in the process and by then the Makefile has
> > > already been created.
> >
> > Mmm. cdbs at work.
> >
>
> Not necessarily. I use cdbs a lot. Patches are applied before
> ./configure but also reversed prior to the clean. I know the CDBS docs
> are not easy to follow but cdbs does support patches to Makefile.in and
> Makefile.am. It is usually best to edit both using cdbs-edit-patch. I'd
> take a closer look but although I'm ok with CDBS, I know nothing about C#.
> :-(
>
> The src/Makefile.am is already patched so it should be relatively
> painless to extend that patch to include the changes to Makefile.am and
> Makefile.in.
>
> The hardest part of the CDBS simple_patchsupport is actually getting
> used to cdbs-edit-patch, particularly when you want to extend an
> existing patch. I sometimes reverse the first patch and delete it,
> reverse any manual changes, run cdbs-edit-patch with the name of the
> patch you just deleted and then make all the edits in that subshell.
> (Sometimes helps to run make clean beforehand too so that dh_clean
> doesn't cause too many problems).
Nice tool that. I'll describe the problem I have with the patching here
and then answer Luis' mail for the rest of the issues he raised.
What I need is for src/blam.exe.mdb (a debug file) to be deleted upon
clean. Otherwise, the second build in a row FTBFS. Now, 'make
clean' (debian/rules clean) is issued too early for the patch to be
applied.
I've just realised that I should add 'rm -f src/blam.exe.mdb' to the
clean portion of debian/rules, but when I fixed it the first time 'round
I thought adding it directly to the makefiles was the only solution (I'm
still getting used to how the deb files work).
>
> > > Ok, if you can't get them to apply soon enough, it's ok to leave those
> > > (but just those) directly in the .diff.gz.
>
> (Carlos: It just complicates using uscan a little - it's easier to
> upgrade to the next upstream release if the entire .diff.gz applies
> within debian/, that's one reason why Luis wanted these out of the .diff.gz)
I know, I've had to update blam inside Debian as well. One of the
changes I'd forgotten I'd made and the other one was the only way I
found to make the build work the second time 'round.
>
> > > linda complains that:
> > > E: blam; Uses cdbs and debhelper.mk, but debhelper Build-Depends is too old.
> > > This package uses cdbs and includes debhelper.mk, but the version of
> > > debhelper the package Build-Depends on is too old. To use
> > > debhelper.mk you currently must Build-Depend on at least debhelper (>=
> > > 4.1.0).
>
> debhelper (>= 5) is a safer bet, together with compat 5. IMHO.
I'll believe you :)
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
Attachment:
signature.asc
Description: This is a digitally signed message part