[Xenomai-core] Packaging issues and licensing issues
Hi, I repost here the issues that I have pointed in wish #4523 on the GNA interface https://gna.org/bugs/index.php?func=detailitemitem_id=4523 which, although it is listed in the bug tracker, is *not* a bug... ;) but there is no other place to put wishes or todo items. Debian offers the module-assistant package, that relies on the kernel-package tools. module-assistant is both a command-line and a dialog-and-menus based tool, to make it very easy to build and package kernel modules. For instance, to build a module package from the ipw2100-source package (for wireless cards), the single following command is sufficient: $ m-a build ipw2100 This downloads the source package, builds the modules and packages them. $ m-a install ipw2100 This command does the same and even installs the built package. However, the current rtai-source in Debian is the only *-source package that cannot be built using module-assistant. This should be corrected in the next packages. I propose that the package be split into 5 packages, anyway: - libxenomai: the libraries, - libxenomai-dev: the development libraries, headers and devel tools (rtai-config, etc.), - libxenomai-tools: the runtime tools (rtai-load, etc.?) - libxenomai-doc: the docs, - xenomai-source: only the sources of modules; should be usable with module-assistant. And the *-source package should be well integrated: the module *.ko files should go into /lib/modules/... so that we can use modprobe directly to load the Xenomai modules. But that should be OK if it is compatible with module-assistant. I have started creating a Debian package mockup (as a week-end hobby, do no expect that I finish it ;)), following the above remarks, and I have found other issues: There are three licenses used in the source code: 1- GPL v2 or later: ./sim/** ./skins/rtai/* ./skins/posix/* ./skins/native/* ./skins/uvm/* ... OK, no problem: the COPYING files are consistent with the license headers in files. 2- GPL v2 or later with exceptions: ./nucleus/** ./include/nucleus/** ./skins/psos+/** ./skins/uitron/** ./skins/vrtx/** ./skins/vxworks/** ... The license headers in files do not mention the exceptions, only the COPYING files do. - You should update the license headers in files. 3- LGPL v2 or later: ./skins/rtai/lib/* ./skins/posix/lib/* ./skins/native/lib/* ./skins/uvm/lib/* ... Problem: only the text for v2.1 is in the COPYING files, not for v2 as mentioned in all license headers in files. - You should update the COPYING files to contain LGPL v2, or update headers in files. My other issue is: what are precisely the licences of every binaries / docs / modules / ... produced by make install? Because the right license files and doc must be provided in binary packages. -- Romain Lenglet
Re: [Xenomai-core] Packaging issues and licensing issues
Romain Lenglet wrote: Hi, I repost here the issues that I have pointed in wish #4523 on the GNA interface https://gna.org/bugs/index.php?func=detailitemitem_id=4523 which, although it is listed in the bug tracker, is *not* a bug... ;) but there is no other place to put wishes or todo items. Ah, thanks ! The mailing list is the best place for yous wishes, since it may start a discussion, and we may even found a volunteer for doing the debian package. The bug is closed. -- Gilles Chanteperdrix.
[Xenomai-core] Packaging issues - part 2
Hi, Some more packaging issues... There is currently no man page for binaries (xeno-config, xeno-info, xeno-load and xeno-test), but there should. It would be nice to build the documentation when building the packages. Patrick, you wrote that it is not possible to build the documentation using packages available in Debian. Could you explain that please? This should be fixed. In addition, I am wondering if it could be useful to package every skin in a separate package, e.g. libxenomai-posix, libxenomai-rtdm, etc. What do you think about that? This would imply to have also one module source package for every skin (e.g. xenomai-posix-source, xenomai-rtdm-source, etc.), and to be careful about dependencies between modules, but it can be manageable. That way, the I-am-dreaming-for packages for RTnet would directly depend on xenomai-rtdm-source and libxenomai-rtdm. There is also an issue about some compile-time flags. I think that there is no risk in enabling and packaging every skin, but how about --enable-x86-sep and --enable-smi-workaround ??? What should be enabled by default (in the standard package)? Should we make several different packages compiled with the different options? How about the many combinations of --enable-periodic-smi, --enable-intel-usb2-smi, --enable-mc-smi, etc., etc.?! From a user/packager point of view, it would be much better if those flags were kernel module parameters, and to have only package / set of modules to deal with. Is it possible to make that change? Would the runtime penalty be acceptable? As for --enable-x86-sep, I guess that it is safe to disable it by default, wether or not users use NTPL, but can someone confirm this? -- Romain Lenglet
[Xenomai-core] Packaging issues - part 3
Hi, One more issue about packaging. It is generally a bad idea to make native packages, i.e. to maintain the packaging files (e.g. the debian/* files) into the upstream repository. Some packaging-related issues will arise, such as typos in package docs, file location issues, etc. and releasing packages that correct such issues should not require to make a new upstream release. I therefore propose to make one separate repository for the packaging, for every distribution, and to have separate bug trackers (although Debian already has its own bug tracker for Debian packages), etc. OK, that's all for the weekend... -- Romain Lenglet
Re: [Xenomai-core] Packaging issues - part 3
Romain Lenglet wrote: Hi, One more issue about packaging. It is generally a bad idea to make native packages, i.e. to maintain the packaging files (e.g. the debian/* files) into the upstream repository. Some packaging-related issues will arise, such as typos in package docs, file location issues, etc. and releasing packages that correct such issues should not require to make a new upstream release. This looks like separated issues: fixes of the debian directory may go in the Xenomai svn repository, and cause a debian package update without a new upstream release. But there are maybe other issues ? -- Gilles Chanteperdrix.
Re: [Xenomai-core] Packaging issues and licensing issues
On Sunday 16 October 2005 08:50, Gilles Chanteperdrix wrote: Ah, thanks ! The mailing list is the best place for yous wishes, since it may start a discussion, and we may even found a volunteer for doing the debian package. Using the debian/rules I did a few weeks ago as a basis for further work, I can work with Romain to develop it further. Not sure that having separate packages for each skin is a good idea, but certainly m-a is worth persuing. Somewhere along the way, it would be wise (in my opinion) to appoint a package manager with write permissions to svn/cvs and file areas - This would relieve the core team of the burden of repository maintenance. Regards, Paul.
Re: [Xenomai-core] Packaging issues and licensing issues
Hi Paul,
Using the debian/rules I did a few weeks ago as a basis for
further work, I can work with Romain to develop it further.
Not sure that having separate packages for each skin is a good
idea, but certainly m-a is worth persuing.
Yes, finally I think that one set of packages for every skin
would be overkill.
As my 2 yen contribution, here is a debian/control file (ok, this
is the easiest task, but someone had to do it...). ;)
As for the rules file, I think that the most difficult will be to
generate the module source package. There is already a skeleton
of a source package generating a module source package, in the
documentation of package module-assistant:
/usr/share/doc/module-assistant/examples/templates-debian-dir.tar.bz2
What I did is to start with dh_make --kmod, then modify the
control file to define the other packages. Then we should try to
reuse module-assistant's template, that is apparently used by
all other module source packages in Debian.
--
Romain Lenglet
Source: xenomai
Section: devel
Priority: extra
Maintainer: Romain Lenglet [EMAIL PROTECTED]
Build-Depends: debhelper (= 4.0.0), autotools-dev
Standards-Version: 3.6.2
Package: libxenomai
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (libraries)
Xenomai is a real-time development framework cooperating with the
Linux kernel, in order to provide a pervasive, interface-agnostic,
hard real-time support to user-space applications, seamlessly
integrated into the GNU/Linux environment.
.
Xenomai is based on an abstract RTOS core, usable for building any
kind of real-time interfaces, over a nucleus which exports a set of
generic RTOS services. Any number of RTOS personalities called
skins can then be built over the nucleus, providing their own
specific interface to the applications, by using the services of a
single generic core to implement it.
.
This package contains the runtime shared libraries.
Package: libxenomai-dev
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (development)
Xenomai is a real-time development framework cooperating with the
Linux kernel, in order to provide a pervasive, interface-agnostic,
hard real-time support to user-space applications, seamlessly
integrated into the GNU/Linux environment.
.
Xenomai is based on an abstract RTOS core, usable for building any
kind of real-time interfaces, over a nucleus which exports a set of
generic RTOS services. Any number of RTOS personalities called
skins can then be built over the nucleus, providing their own
specific interface to the applications, by using the services of a
single generic core to implement it.
.
This package contains the development environment.
Package: libxenomai-tools
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (tools)
Xenomai is a real-time development framework cooperating with the
Linux kernel, in order to provide a pervasive, interface-agnostic,
hard real-time support to user-space applications, seamlessly
integrated into the GNU/Linux environment.
.
Xenomai is based on an abstract RTOS core, usable for building any
kind of real-time interfaces, over a nucleus which exports a set of
generic RTOS services. Any number of RTOS personalities called
skins can then be built over the nucleus, providing their own
specific interface to the applications, by using the services of a
single generic core to implement it.
.
This package contains command-line tools for testing Xenomai.
Package: libxenomai-doc
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (documentation)
Xenomai is a real-time development framework cooperating with the
Linux kernel, in order to provide a pervasive, interface-agnostic,
hard real-time support to user-space applications, seamlessly
integrated into the GNU/Linux environment.
.
Xenomai is based on an abstract RTOS core, usable for building any
kind of real-time interfaces, over a nucleus which exports a set of
generic RTOS services. Any number of RTOS personalities called
skins can then be built over the nucleus, providing their own
specific interface to the applications, by using the services of a
single generic core to implement it.
.
This package contains documentation on the usage of the libraries.
Package: xenomai-source
Architecture: i386 powerpc
Depends: module-assistant, debhelper (4.0.0), make, bzip2
Recommends: kernel-patch-adeos (=20050809)
Description: Xenomai real-time framework (kernel module source)
Xenomai is a real-time development framework cooperating with the
Linux kernel, in order to provide a pervasive, interface-agnostic,
hard real-time support to user-space applications, seamlessly
integrated into the GNU/Linux environment.
.
Xenomai is based on an abstract RTOS core, usable for
Re: [Xenomai-core] Packaging issues - part 3
This looks like separated issues: fixes of the debian directory may go in the Xenomai svn repository, and cause a debian package update without a new upstream release. But there are maybe other issues ? Alright, but we should be able to make changes in both the Xenomai code and the Debian files, independently. If a package has been released, then if we want to release a new revision of the package that corrects Debian-only issues, then we must be able to ignore any modification in the repository that do not concern the Debian files, to create the new package. We can do that with either separate repositories, or branches in svn. -- Romain Lenglet
[Xenomai-core] Cosmetic changes to script xeno-config + man page
Hi,
Here is a man page that I have written for xeno-config.
Philippe, you will have to create a man directory to contain
that man file and an GNUmakefile.am file that contains:
man1_MANS = xeno-config.man
dist_man1_MANS = $(man1_MANS)
And add man to the SUBDIRS in the root GNUmakefile.am.
I will write man pages for xeno-info, xeno-load and xeno-test
when I have some time this week.
By the way, I noticed that the output of function usage() in that
script was wrong. Here is a correct version, to replace the one
in scripts/xeno-config.in:
usage ()
{
cat EOF
Usage xeno-config OPTIONS
Options :
--help
-v,--verbose
--version
--cc
--cross-compile
--arch
--subarch
--prefix
--config
--mod*-cflags,--kernel-cflags
--xeno-cflags,--fusion-cflags
--xeno-ldflags,--fusion-ldflags
--posix-cflags
--posix-ldflags
--uvm-cflags
--uvm-ldflags
--linux-dir,--linux
--linux-ver*
--mod*-dir
--sym*-dir
--lib*-dir,--libdir,--user-libdir
EOF
exit $1
}
And I also noticed a few echos with unquoted * in function
verbose(). Here is a correct version without any *:
verbose ()
{
echo xeno-config --verbose
echo --version=\${XENO_VERSION}\
echo --cc=\$XENO_CC\
echo --cross-compile=\$CROSS_COMPILE\
echo --arch=\$XENO_TARGET_ARCH\
echo --subarch=\$XENO_TARGET_SUBARCH\
echo --prefix=\$XENO_PREFIX\
echo --config=\$XENO_CONFIG\
echo --kernel-cflags=\$XENO_KERNEL_CFLAGS\
echo --xeno-cflags=\$XENO_BASE_CFLAGS\
echo --xeno-ldflags=\$XENO_BASE_LDFLAGS\
echo --posix-cflags=\$XENO_POSIX_CFLAGS\
echo --posix-ldflags=\$XENO_POSIX_LDFLAGS\
echo --uvm-cflags=\=$XENO_UVM_CFLAGS \
echo --uvm-ldflags=\=$XENO_UVM_LDFLAGS\
echo --module-dir=\=$XENO_MODULE_DIR\
echo --symbol-dir=\$XENO_SYMBOL_DIR\
echo --libdir=\$XENO_LIBRARY_DIR\
echo --linux-dir=\$XENO_LINUX_DIR\
echo --linux-version=\$XENO_LINUX_VERSION\
}
--
Romain Lenglet
xeno-config.man
Description: Unix manual page
