Hi,
I am currently trying to create a Debian package for NOX. I encountered
many issues with NOX's autotools-based packaging that make it very
difficult to package, listed below.
I propose two strategies to handle those issues and obtain a NOX version
that can be properly made into a Debian package:
1) I have patches that solve almost all those issues. It's a lot of
work, it's not finished, and I'm not yet satisfied with the result. Are
you OK to do such an overhaul of NOX's build system? I.e. would you be
willing to review and integrate such patches?
2) It's such a frustrating work that I'd just prefer to fork NOX and do
a clean, minimal version including only a working nox-core
implementation and a new set of configure.ac / Makefile.am files redone
from scratch. The rest of the code could be packaged separately, from
another source.
(I think the name "Forkt NOX" would be good for this ;))
Which strategy do you think is better?
My issues:
- the use of a heavy-handed boot.sh script to configure the parts of the
system to build, instead of using Autoconf's standard AC_ARG_ENABLE
macros to add --enable-X / --disable-X options to the configure script,
and then defining and using variables that can be tested in Makefiles to
enable options;
- the use of a custom M4 macro for testing for Python, instead of using
Automake's AM_PATH_PYTHON which at least correctly selects the correct
Python version when multiple versions of Python are installed in the
system and defines correctly the installation directory for Python files
($pythondir):
- pythondir is calculated by AM_PATH_PYTHON using this code:
from distutils import sysconfig
print sysconfig.get_python_lib(0,0,prefix='$prefix')
i.e., this code correctly takes into account the prefix
- PYTHON_SITE_PKG is calcualted by AC_PYTHON_DEVEL (used by NOX)
using this code;
import distutils.sysconfig
print distutils.sysconfig.get_python_lib(0,0)
i.e., it doesn't take into account the configured prefix so
PYTHON_SITE_PKG cannot be used as-is as an installation dir
- at install time, all Python sources are installed in prefix/..., then
compiled using the configured version of Python, and then deleted for no
good reason; this makes it impossible to install NOX to support multiple
versions of Python in the same system. The Debian way, e.g. using
python-support, is to: first install the Python sources in a Python
version-independent directory, normally $prefix/share/pyshared/, and
then let python-support compile the sources for every version of Python
installed in the system, e.g. into
$prefix/share/python-2.6/site-packages/,
$prefix/share/python-2.4/site-packages/, etc.
- all the Python sources are installed into $prefix/bin, even Python
files that are not meant to be executables; this is just wrong: Python
sources should normally be installed into $prefix/share/python-*/ (or
preferably into $prefix/share/pyshared/), Python extension modules (.so
libs, etc.) should be installed into the dir for each supported version
of Python ($exec_prefix/lib/python-*/site-packages);
- just anything is installed along with the Python source files (listed
in the NOX_RUNTIMEFILES variables): I've found Swig *.i files, C++ *.cc
source code files, *.sh test scripts, config files (meta.xml) etc. Those
should really be installed separately, into different directories.
- specifically for the meta.xml, it would be better to install them into
a specific directory containing only those files, e.g. $pkgdatadir/
(i.e. $prefix/share/nox/...);
- test files should not be installed at all (cf. the .../t/ directories
for instance);
- the SSL certificates are generated at build time, included into the
dist archive, and then copied at install time. Without modification, it
would mean that all users installing from a dist archive or from a
Debian package made from this unmodified build system would use the same
SSL certificate, which of course must be absolutely avoided. The SSL
certificates should instead be generated much later, at package
installation time. They should at least not be generated at build time,
and not be included into the dist archive.
- there are several hard-coded paths in the source code, e.g. in
switch_command.py there is this line:
sys.path.append('/opt/nox/bin')
- a lot of files are just not listed in the Makefiles, and as a
consequence are not included in the dist archive (generated with "make
dist"), and sometimes not even built or installed. For instance, the
src/scripts is not even listed in the SUBDIRS of src/Makefile.am, so its
files cannot be included into the dist archive. Or the *.txt files in
src/tests/.
- some temporary files are not cleaned properly. For instance,
src/lib/dhparams.c should be in the CLEANFILES and should not even be
present in the Git repository;
- some Makefiles handle files in subdirs, e.g. src/include/Makefile.am
takes care of all the files in subdirectories. That one is not too bad,
but part of the files in src/nox/ are handled by src/Makefile.am, and
the rest is handled by src/nox/Makefile.am, which is confusing. Why not
just have one Makefile.am per directory, as usual, and let each
Makefile.am handle all the files in its directory, and only those files?
FYI, I'm working using the openflow-1.0 branch.
Best regards,
--
Romain Lenglet
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
