Quoting Curt Arnold <[EMAIL PROTECTED]>:
On Aug 11, 2007, at 9:13 AM, Pau Garcia i Quiles wrote:
Hello,
I am trying to package log4cxx 0.9.8 (subversion checkouts,
actually) for Debian and Ubuntu. I succeeded with a 20070712
checkout and with a 20070810 checkout.
The version number 0.9.8 implies binary compatibility with 0.9.7 which
will not be the case. The anticipated next release is 0.10.0.
I do not agree. Binary compatibility is stated by soversions, not by
source versions. The only "compatibility" a 0.9.8 number would "imply"
is "the API in 0.9.8 is more or less the same as in 0.9.7, there are
no big changes".
Unfortunately, there are some nasty issues preventing the packages
to spread:
* What is the build system? ant? autotools? I thought it was
autotools until 0.9.7, ant from then on, but three was commit on
July 30th fixing the autotools build system, therefore I have
doubts now (my packages are using ant for now)
Maven (delegating to Ant) will be used to prepare the documentation,
web site and source distributions including IDE project files (Visual
Studio, XCode, maybe Sun Studio) for those so inclined. When the
directory structure was rearranged to make it consistent with the Maven
Standard Directory layout, the autotools build was temporarily broken
until the corresponding changes could be made by Andreas Fester who
maintains it.
Do you mean log4cxx will be buildable using both chains, autotools and
Maven-Ant?
* Downloading apr, cppunit, etc in the build process is
unacceptable for Debian and Ubuntu. The build farm has no Internet
access for a very good reason: make sure we will be able to build
the package anywhere, anytime; no missing files. Is there any good
reason to download apr, cppunit, etc instead of using the already
installed versions?
The concept of installed versions doesn't carry over to Windows and way
back in the day, prepackaged apr-1's were a rarity. The download of
apr was problematic and currently there is a snapshot of apr-1.2.9 and
apr-util-1.2.8 in the SVN tree. However, can't do the same for cppunit
as it is not Apache licensed. Both builds can ignore the SVN snapshot
and use the installed versions.
I did not know I could ignore the SVN snapshot and use the installed
version, thanks.
If you have any ideas on how the
dependencies could be managed better that would work across platforms,
let me know. I was thinking that Maven (which handles Java
dependencies) might be able to be exploited to deliver the source
tarballs (or jars), but I don't think it has been used that way yet.
I have my own idea on that, but I guess you won't like it :-)
I would just have something like this in the INSTALL: "To build
log4cxx, you need apr (>= 1.2.9), apr-util (>= 1.2.8) and libcppunit
(>= 1.12)". Then some parameters like
"--with-apr=/usr/local/apache/apr
--with-apr-util=/usr/local/apache/apr-util" etc to force the
buildsystem to use a special version or find the installed version in
a non-default location.
I don't think log4cxx should fix the installation of software required
to build log4cxx. The user must be intelligent enough.
Thank you.
PS: In case you want to build the packages yourself, you can
download the .orig.tar.gz and the .diff.gz from
http://ppa.dogfood.launchpad.net/pgquiles/ubuntu/pool/universe/l/log4cxx/
Andreas Fester maintains a log4cxx package for Debian at
http://littletux.homelinux.org/projects.php?fileid=apache. He should
be watching this list and will probably have more to add.
I did not not that either. I packaged log4cxx because we use it at
work and installing software from source makes our systems dirty.
If Andreas Fester is providing packages, I guess it makes no sense to
have my own packages (his packages build using autotools, mine use
ant, but that's not important).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
