Re: dpkg-source: unrepresentable changes to source
hi
On Mon, Nov 12, 2001 at 01:47:04PM +0100, Florian Hinzmann wrote:
> Hello!
>
>
> On 04-Nov-2001 Steve M. Robbins wrote:
>
> > In your original mail, the question was what to do about symbolic
> > links like "missing --> /usr/share/automake/missing". The answer is:
> > replace them by the file to which they are linked.
>
> Yes, thanks. I do understand another part of this autoconf
> mess now.
> I thought the autotools might be able to copy files instead of
> making symlinks. But it looks like I have to replace the symlinks
> with files by myself.
or otherwise add --copy to libtoolize
but as I said in the other e-mail, I do not agree with this solution
> Do you or does anyone here have a Makefile/sh
> snippet which I might use for this task?
>
>
> > the old version is "nonexistent". Normally one would expect the
> > source distribution to include these files (INSTALL, install-sh, etc).
>
> No, I am packaging from the official release tar file. These needed
> files are not included in upstream source.
> Upstream provides an autogen.sh script. The user is supposed
> to run that script and a normal "make;make install" works
> after that.
this happens but is not very nice: it forces people to have auto* installed
the whole idea of auto* is that the
-) the developer prepares the program using auto*
-) the user who wants to compile does not need auto*
> > However, after a number of bug reports, I have changed my mind. It
> > doesn't pay to mess around with automake/autoconf/libtool and stuff
> > inside debian/rules. All I do now is: make any tweaks to Makefile.am
> > or configure.in, re-run the auto-stuff on my local copy, and live with
> > the enlarged diff that results.
well this is a possible solution,
(but as you have seen, the diff is as big as the tar.gz)
a.
--
A Mennucc
"È un mondo difficile. Che vita intensa!" (Renato Carotone)
Reply to: