On Sat, Jan 14, 2006 at 08:45:07AM -0200, Henrique de Moraes Holschuh wrote: > On Fri, 13 Jan 2006, Steve Langasek wrote: > > There are *always* libraries in a state of transition in Debian. Using the > > Debian libtool means limiting those transitions to packages which have a > > valid reason for depending on the transitioning library, instead of giving > > us transitions that ripple through all the indirect reverse-dependencies. > > > > Just to be clear, relibtoolizing should only need to be a one-time thing. > > We differ in opinions, here. I'd rather people wrote a proper > autogen.sh-like script for their packages, so that they could easily and > PAinlessly autoreconf (or the equivalent) their packages often. I completelely agree. When I read Steve's e-mail about libtool (referenced earlier in this thread), I was again confirmed in my position (although I think Steve doesn't agree with it) that running the autotools (and that includes libtoolize) from debian/rules is a very good idea: It makes sure that the latest (and presumably best) version of everything is used. And that "everything" includes libtool and autoconf, but also Makefile.am and configure.ac. Of course I know the classical argument against this: To build a program, you should only need to do "./configure;make;make install". configure is the platform independant script, autoconf should only be used by upstream. I strongly disagree with this line of argument. Autoconf was indeed created to allow building on platforms which don't have any special portability tools installed. In particular, they don't need to have autoconf installed. However, this is completely irrelevant if we _do_ have them (and on Debian we do, of course). So the distribution of the program is in such a way that it can be built on half-broken architectures? What do we care, we can just build the thing from source, thus ensuring we don't have a FTBFS, and ensuring that the sources we have in the source package are actually the sources of the binary package. The user who only downloads the tarball needs to do nothing more than "./configure;make;make install". But running "./autogen.sh;make;make install" (if available, otherwise running "libtoolize --force;aclocal-1.9;automake-1.9 -a;autoconf;./configure;make;make install" ) gives better results in many cases, and should IMNSHO always be done to avoid accidental use of old versions of anything. The thing is, in the ideal world relibtoolize would be a one-time thing, and autotools should only be needed by upstream. Come to think of it, relibtoolize wouldn't be needed at all of course. But in this not se ideal world, bugs are fixed, both in Makefile.am/configure.ac and in the autotools themselves. The best way to handle that is to rebuild everything from source, and that includes ./configure and ./libtool. > For most up-to-date packages re. autotools, this is just a call to > autoreconf. autoreconf has the annoying property of preferring automake 1.4 if it is installed. So you need to set the environment to the proper versions for it to work. I prefer directly calling the correct version of it. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature