[Evolution] r1106 - in /unstable/evolution/debian: changelog control evolution-mail.desktop evolution-plugins-experimental.install evolution-plugins.install evolution.install evolution.links lintian/evolution-plugins lintian/evolution-plugins-experimental rules

[Loïc Minier]

On Mon, Dec 15, 2008, Yves-Alexis Perez wrote:
> At the same time, if someone could review the changes I made, I'm not a
> gnome packager expert, especially with such a release. I've followed
> some changes made by Ubuntu, dropped and created some binary packages
> where it was needed, but I'm not 100% sure.

 Critical things to do when reviewing new GNOME modules and in
 particular evo:
 - diff configure.ac/.in and read the changes in full
 - read NEWS entries carefully
 - look for SONAME changes, either in configure.in/.ac or Makefile.am or
   after the build
 - make sure you installed everything (usually list-missing helps)
 - if you like, check ChangeLog, README etc. for interesting changes

> In the same vein, why are all the lib packages not named like
> recommended (libetrouc-42-1 and not libetrouc42-1, for example). For the
> new binary packages I had to create I followed the existing scheme
> (libebackend1.2-0) so it's consistent, but why not using the “correct”
> stuff, instead of providing (abusing) lintian overrides?

 It's a relatively common scheme to not use the "-"; perhaps we should
 rename to use a dash in all cases and be consistent, it might even be
 recommended for policy, but some packages wont change before a while
 (libgtk2.0-0 libpango1.0-0 etc.).  Personally I prefer without the
 dash, but I wouldn't mind.

 If you consider renaming to add a dash, please be nice and coordinate
 with Ubuntu to avoid a massive delta.  :-)

> Ok, anyway you should be able to build the three packages, and I would
> really love some review before any upload to experimental.



 The reason your autoreconf is failing like this:
acinclude.m4:236: the serial number must appear before any macro definition
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:76: warning: macro `AM_VERSION_SET' not found in library
configure.ac:82: warning: macro `AM_OPTIONS_SET' not found in library
...
configure.ac:367: error: possibly undefined macro: AM_TCL_LOAD
configure.ac:397: error: possibly undefined macro: AM_TYPES
configure.ac:432: error: possibly undefined macro: AM_DEFINE_MUTEXES
autoreconf: /usr/bin/autoconf failed with exit status: 1

 is because eds has an embedded libdb copy, this db copy needs custom m4
 macros, but doesn't use automake and doesnt specify how to locate the
 additional macros in libdb/dist/aclocal/.  Usually this is passed via
 ACLOCAL_AMFLAGS in Makefile.am, but libdb doesn't use automake, or
 AC_CONFIG_MACRO_DIR in configure.ac.  I tried putting this in the two
 configure.* scripts, and in the toplevel Makefile.am, but to no luck.
 The reason is that libdb invents its own aclocal.m4 generation, see the
 s_config script.  Conclusion: I'm not tempted to look into this.

 You can probably workaround the issue by patching out the libdb aux dir
 in configure.ac.

   Bye
-- 
Loïc Minier