[Pkg-clamav-devel] redo debian/rules with less dh for clamav

[Scott Kitterman]

On Saturday, March 22, 2014 13:15:34 Scott Kitterman wrote:
> The current squeeze packages don't autoreconf, so that's fine and expected.
> 
> Scott K
> 
> On March 22, 2014 12:46:32 PM EDT, Sebastian Andrzej Siewior 
<bigeasy at breakpoint.cc> wrote:
> >On 2014-03-22 11:33:07 [+0100], Andreas Cadhalpun wrote:
> >> Hi,
> >
> >Hi,
> >
> >> On 22.03.2014 00:17, Sebastian Andrzej Siewior wrote:
> >> >On 2014-03-21 17:27:09 [+0100], Andreas Cadhalpun wrote:
> >> >>Because they are only created, when PO2DEBCONF is yes, which it
> >
> >normally is
> >
> >> >>not. (I actually don't know, when this will be yes.)
> >> >
> >> >Is there an error if it tries to remove files which aren't there?
> >> 
> >> The problem is different: These files are not created during build,
> >
> >so if
> >
> >> they get removed, the build fails.
> >
> >Now I got this. PO2DEBCONF is a variable which may be set. This makes
> >sense then. Now I wanted to ask if we could always run PO2DEBCONF but
> >then I noticed that the master aren't there anymore. Looking at the old
> >git I must say that the file was never there. So. Who knows more about
> >this? :)
> >
> >> >>I build with the old rules file (with added faketime) and compared
> >
> >the
> >
> >> >>result to the packages build with the new rules file. I didn't find
> >
> >any
> >
> >> >>fundamental difference, only:
> >> >>  * DEBIAN/control reads now 'libclamav6 (>= 0.98.1)' instead of
> >
> >'libclamav6
> >
> >> >>(>= 0.98.1+dfsg)', thanks to the symbols file.
> >> >>
> >> >>  * A few bytes in the binaries differ and I can't figure out why.
> >> >>
> >> >>Thus I think we can switch to the new debian/rules, assuming it
> >
> >still builds
> >
> >> >>in oldstable/stable.
> >> >
> >> >Great. I'm going to build test it on stable/oldstable on a few
> >> >architectures and see how it goes.
> >> 
> >> It builds fine with wheezy on amd64.
> >
> >Tested kfreebsd-amd64/wheezy, armel/wheezy, fine.
> >
> >It doesn't work on squeeze on any architecture. The problem is:
> >|configure.ac:25: warning: macro `AM_PROG_AR' not found in library
> >|configure.ac:25: error: possibly undefined macro: AM_PROG_AR
> >|
> >|      If this token and others are legitimate, please use
> >
> >m4_pattern_allow.
> >
> >|      See the Autoconf documentation.
> >|
> >|autoreconf: /usr/bin/autoconf failed with exit status: 1
> >|dh_autoreconf: autoreconf -f -i returned exit code 1
> >|make: *** [build] Error 9
> >
> >That macro is not available in squeeze's automake version. The current
> >source there does not execute autoreconf.
> >That means that is different. The only reason why we do autoreconf in
> >in the first place is because we purge a few directories
> >(rar for instance) and need to update Makefile.in files. Would it work
> >to execute autoreconf as part of the upstream source split and keep it
> >as a patch?
> >
> >After I dropped the autoreconf part it built on squeeze-i386.

Maybe something like (totally untested):

if '$(cut -c1 /etc/debian_version)' = '6' then \
  dh $@ --parallel \
else \
  dh $@ --parallel --with autoreconf \
fi

Scott K