Re: dpkg-source: unrepresentable changes to source
Florian,
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.
More puzzling, though, is that the output of "dpkg-source" says that
the old version is "nonexistent". Normally one would expect the
source distribution to include these files (INSTALL, install-sh, etc).
The absence of such files suggests that either you are packaging from
CVS, or perhaps that you are deleting the files in debian/rules
"clean".
If you're building from CVS (I'll ignore the question "why?"), you'll
need a ".orig.tar" file to upload anyway, so the best thing to do
is "make dist", and work from the resulting tarball which will have
all the required files.
If you are deleting the files yourself, then the fix is simple: don't
do that. Notwithstanding autotools-dev README, I find the best policy
for dealing with auto-based packages is to simply drop in the latest
/usr/share/misc/config.{guess,sub}, if required, and build.
When I packaged my first package, I thought it would be a good idea to
make the diff as small as possible. I read the diff to double-check
the modifications I make to the sources when I package things. Having
the diff of "configure" and "config.guess" and the like mixed in was
annoying, so I used to remove "configure" in debian/rules clean, and
run "autoconf" in debian/rules build-stamp. The diff is much smaller
and easier to read.
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. If you need to run-something like
autogen.sh that has "automake --add-missing --force", just replace the
resulting symlinks by the corresponding file. Again, you need only do
this once.
On Sun, Nov 04, 2001 at 08:18:47PM +0100, Florian Hinzmann wrote:
> >> In fact I do run autogen.sh in the clean rule. Please
> >
> > WHAT? You should CLEAN, not generate something in the clean rule.
>
> From /usr/share/doc/autotools-dev/README.Debian.gz:
>
> > Do note that a properly done autogen.sh invocation runs before dpkg has a
> > chance to build the source package, so as to make sure an user does NOT need
> > any of the programs called by autogen.sh to build the package. This will, in
> > fact, ease the load on auto-builders as well since the program will build much
> > faster.
>
> Please tell me where I should call the autogen.sh if not
> in clean rule to archive this.
As I read this section, Henrique is talking about regenerating files
that are not stored in CVS. I don't know why he put this in the
README. Debian packaging assumes you start from a "source
distribution" tarball that *includes* all these files.
Actually, I find Henrique's wording is slightly confusing. It is not
true that the configure script and Makefile.in are "supposed to be
regenerated at every build". These files need to be rebuilt each time
their input (i.e. configure.in) changes. No more often than that.
You really only need to worry if you patch configure.in or
Makefile.am.
In addition, you need to worry about config.{guess,sub}
*if used by the sources*. However, it's easy enough to
drop in the latest version when you prepare a new upload.
The rest of /usr/share/doc/autotools-dev/README.Debian.gz
can be safely ignored.
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: