Romain Beauxis wrote: > Hi all ! > > I came to the oss4 project very recently, and was happy to see it has > improved, and could possibly overcome some of the limitations of ALSA. > > Also, thanks to your new licensing, oss4 should fit for an official inclusion > into debian ! > > So, I volontered to prepare a package: > http://bugs.debian.org/483856 > > In order to prepare the package, I would like to ask some questions. > > First of all, concerning the licence: > * Is it the whole code GPLed ? (naive question) > I mean that even if the global licence is GPL, there could be other parts > which are not GPL. This could also include the documentation that could be > GFDL for instance.. Those licencing questions are very important for an > inclusion, and often thake time to check (and are really boring too), so your > help is welcome here :) > There are some closed source packages in OSS but they are not included in the tarballs. So all drivers included in the GPL source package are under GPL. Some header files and/or sample programs may be under the BSD license but all this code is for user land only. > * Which version should be packaged ? For instance, I have has issues with the > libsalsa build, but as I read, it was fixed in the current developement > version. Hence if the developpement version is stable enough, it could be > considered for the package. > The development version (in particular the hg one) is too dangerous to be used in "production". The 4.0 version is safe but may lack some bug fixes (we have been trying to include most of them in v4.0 too).
We have planned to make v4.1 the "stable" version after the summer. So it might be a good idea to wait few months before inclusion. In addition I have been planning to implement a script/utility that takes the OSS sources and "injects" the kernel space code to the Linux stock source tree. > Then come the important questions. If I get it well, oss4 is composed of > several parts: > * dynamic libraries, mainly libsalsa and libOSSlib (names by memory) > * binary programs, suchs as ossmix, ossxmix etc.. > * kernel modules > > So, my plan to prepare a package is to have the following binary packages: > * libosslib and libsalsa packages for each dynamic library. Possibly a single > package, or merge with the -utils package if the libs are meant to be > private. > * oss4-utils for the console utilities > * oss4-xutils for the X11 utilities > * oss4-modules-source for the kernel module code source. > > Then, the user would install the binary packages and build the modules > against > its own kernel, using module-assistant, which does usually a great job. > I think this is pretty much the best solution. > So far, if I inderstand well your build system, after invoking configure and > make build, all the binary packages can be created using the data that is > inside the prototype directory. > > The only question is for the module build. So far I havn't been able to build > them without using the install.sh script. I would like to be able to create a > tarball containing the module code, which would be installed by the > oss4-modules-source package in /usr/src. > Under Linux it's necessary to compile all kernel modules against the kernel version that is used in the target system. The only way that works is to compile part of the code in the target system after installing the files (install.sh). This doesn't work when the modules are to be shipped together with the kernel. It will be necessary to replace the configure script of OSS (ase well as setup/srcconf.c) with something that produces modules that can be compiled together with the kernel. > Then module-assistant would unpack the tarball > in /usr/src/modules/oss4-modules, build them there and create a debian > package from the resulting modules. That way, the user obtain also a .deb for > the modules, which can be removed, upgraded etc.. > > Would it be possible ? > The main problem when installing OSS4 in Linux is that that the kernel development environment (kernel-headers, gcc, binutils, etc) needs to be installed in the target system. This is something I would like to get fixed. So (IMHO) including anything that needs to be compiled in the .deb files is not good idea. > Then, a secondary packaging issue, I will change so things that the current > system is doing. In particular, deleting the alsa modules is not acceptable. > In debian, there is a /usr/sbin/alsa command that can be used to unload alsa > modules, so it would better use this. > Right. Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
