Re: dpkg-source: unrepresentable changes to source

[A Mennucc1 <debian@Tonelli.sns.it>]

hi

I have started seeing these errors myself a few months ago

problem was, I had upgraded to woody, and the new 
autotools create symlinks by default instead of real files

solution (from my xmorph package): run ./autogen.sh once, and
 put in the debian/rules 

........
build: build-stamp
build-stamp:
	dh_testdir
	libtoolize -f
	gettextize -f
	automake --add-missing
	./configure --prefix=/usr --mandir=/usr/share/man \
		--infodir=/usr/share/info 
	$(MAKE)
	touch build-stamp

clean:
	dh_testdir
	dh_testroot
	rm -f build-stamp 

	# Add here commands to clean up after the build process.
	-$(MAKE) distclean
	find -type l | xargs -r rm 
	dh_clean
........

the build-stamp stuff recreates the symlinks, and the 'find -type l | xargs
-r rm' destrys them


note that if your package use symlinks itself you should put an explicit
list of files in the find

note that the above is simplificative; you may wish to call
the ./autogen.sh script from debian/rules, 
which actually recreates all autotool's generated files in the autobuilders;
see below


On Mon, Nov 12, 2001 at 01:56:52PM +0100, Florian Hinzmann wrote:
> On 04-Nov-2001 Eduard Bloch wrote:
> >#include <hallo.h>
> > Florian Hinzmann wrote on Sun Nov 04, 2001 um 08:18:47PM:
> > 
> >> I can't do a configure run as there is no configure script!
> >> I do have to run the autotools scripts.
> >> 
> >> The question is when to run it. Before or after the Debian
> >> diff is built.
> > 
> > Well, if you _need_ the makefile to clean the cruft after the build, you
> > may run autogen.sh once, then "make clean", then remove the fresh
> > created symlinks, then dh_clean. IMHO.

if you do it the proer way , you dont need: after the build, the Makefile is
there, so you call 'make distclean' once, and then you delete the symlinks

> Not possible. There have been many bugreports and the 
> way described in doc/autotools-dev/README.Debian.gz is one
> solution to this problem.
> The autobuilders are not the problem by themselves. They 
> fail or may fail because of newer versions of automake/autoconf/etc.

ok: this has happened to me in the past

there are philosophical two ways to do things:

(M) trust your locally generated scripts
(A) trust the autobuilder's autotools to regenerate the scripts

I use (M) wrt the stuff created by  automake aclocal autoheaders autoconf
and (A) wrt the stuff created by libtool gettext etc etc
 
there is a reson for this , coming from my experience:
(more explanations on request)

> are not compatible to older versions at all times. Therefore 
> the autobuilders should not have to run the autotools. 

well, it depends... but I substantially agree

> Therefore
> I have to run them before creating the diff and this is what
> I am trying to do.

I dont understand what you mean

a.


-- 
A Mennucc
 "È un mondo difficile. Che vita intensa!" (Renato Carotone)