[Pkg-ime-devel] libchewing1 and scim-chewing
Osamu Aoki
osamu@debian.org
Tue, 1 Feb 2005 08:33:34 +0100
On Tue, Feb 01, 2005 at 02:57:11PM +0800, Andrew Lee wrote:
> Osamu Aoki wrote:
>
> >2 major problems. One minor problem fixed in SVN by me. (Missing
> >README.Debian.
> >
> >
> I removed README.Debian in libchewing on SVN, cause all the information
> has mentioned in the description of control file, and copyright file.
>
> >* What is the license? Source package say LGPL while SVN say GPL.
> >
> >
> It should be LGPL, see the upstream web site:
> http://chewing.csie.net/license.html
>
> Sorry, I didn't look up the source when I change the copyright file for
> Kanru.
>
> >* Why you comment out
> >
> >#ifneq "$(wildcard /usr/share/misc/config.sub)" ""
> ># cp -f /usr/share/misc/config.sub config.sub
> >#endif
> >#ifneq "$(wildcard /usr/share/misc/config.guess)" ""
> ># cp -f /usr/share/misc/config.guess config.guess
> >#endif
> >
> >This is not right.
> >
> >
> I guess Kanru did a mistake on following Enrico Zini's changes. :p
It may build this way but this does not seem to be autotools-dev
README.Debian suggests.
! The outdated GNU config.{sub,guess} problem and solutions:
! ----------------------------------------------------------
!
! GNU autotools need the config.sub (and sometimes config.guess) file when the
! AC_CANONICAL_HOST, AC_CANONICAL_SYSTEM macros are used, and also when libtool
! is in use. It might need them in other circumstances, so don't hold your
! breath.
!
! An out-of-date config.sub will break builds in any architecture it doesn't know
! about. The same goes for config.guess, if it is used (so, don't use it, read
! "Calling GNU configure properly" above and call configure properly).
!
! To fix this particular problem automatically, we need both a source of fresh
! copies for config.{sub,guess} in Debian, as well as a way to get them inside
! the packages during their build. autotools-dev provides the fresh copies of
! config.{sub,guess} for any programs that might need them (in /usr/share/misc),
! including automake and libtool.
!
! By inserting some code in the debian/rules file, one can guarantee that
! config.sub and config.guess are up-to-date before configure needs them. There
! are a number of different ways to accomplish that.
!
! When one does not need to care about non-Debian builds of the source, the best
! method is to use symbolic links. It avoids adding the config.guess and
! config.sub updates to the compressed diff file in the source package, and it is
! far simpler and more elegant then the other methods. The debian/rules file in
! the examples/ directory implements the symlink method. A build-dependency on
! autotools-dev is required for this method, of course.
!
! When one wants the updated files in the source package, the clean target is the
! best place for adding the proper code: it guarantees the updated files will
! make it to the source package when dpkg-buildpackage is run. The whole process
! can be safely automated, and config.guess and config.sub will be updated at
! every build, then.
Also HMS said along this line:
+Basics:
+You have two good choices, and one bad choice for packaging upstream source
+which uses automake and autoconf and contains generated files:
+
+ 1. Tolerate the big diff size, and run the autotools stuff before you
+ create the debian source package. This is what I usually do. If
+ you do this, go read the following section.
+
+ 2. Patch the autotools files (*.in, *.am) at build time, make sure all the
+ build dependencies are 100% correct (hint: conflicting with
+ autoconf2.13 is *always* a good idea if you're not using autoconf 2.13
+ and automake 1.4). This means that the autobuilders will have to rerun
+ the entire thing, and so will the users, etc.
+
+ When you're doing a full dpatch-based packaging, this choice makes
+ sense.
+
+ 3. Live with whatever crap upstream used. You do *not* have this choice
+ if libtool is being used, BTW. And it is a bad choice IMHO, I'm yet
+ to see any distribution with better autoconf, automake, libtool and
+ gettext packages than Debian. (I do have a lot of experience on this :P
+ but strongly discourage to do this. Bad choice.)