Dev talk:Compliance

Is Kiwi-LTSP compliant?

 * src: http://kiwi-ltsp.svn.sourceforge.net/viewvc/kiwi-ltsp/trunk/kiwi-ltsp/ltsp/include/
 * concerning: https://code.launchpad.net/~jigish-gohil/ltsp/ltsp-trunk/+merge/121327

The change Cyberorg is proposing is just wrapping our command calls to kiwi-ltsp functions while in my opinion the appropriate kiwi-ltsp library functions should be merged into the ltsp trunk. My reasoning for this is threefold:
 * 1) First, abstraction to common functions, this can be done more easily when code is in the same branch. Different distro specific functions can be compared next to each other and the commonalities merged to a common function.
 * 2) Secondly, sharing of ideas and solutions, which can also be done more easily if different distro specific code is structured in the same way. Distro's who don't have a particular functionality can look at the implementation of another distro and create the same thing for their distro. They might even create a layer of abstraction (1) and perhaps improve the original code. Also, when more code is abstracted, more time can be spent developing new functionality for one's own distro. When an Ubuntu maintainer fixes some common code, every distro using that will benefit from that.
 * 3) Thirdly,  it would be highly preferable if the command syntax is the same across all distributions. This makes it easier to create generic documentation  and offer more consistant support in the various ltsp support channels. For instance, does kiwi support ltsp-chroot --mount-package-cache?


 * Nothing prevents from this being done, we can wrap our functionalities under upstream functions and use upstream commands or kiwi-ltsp commands, anyone interested in looking at what we are doing under those functions can look it up in kiwi-ltsp function libraries[1] sourced in vendor-funcions. If there is anything common and is available upsteam we can drop it from kiwi-ltsp function libraries. At the moment our focus is in getting kiwi-ltsp working well on openSUSE first and make it distribution independent by allowing users to build ltsp chroot/image on distros that do not have kiwi ported.

Really, this calls for a critical look at our design and what we want to achieve with it. Our efforts can be put in making dracut as standard LTSP initrd creation tool on all distributions, add functionalities we need in that tool, this will save a lot of duplication that goes in distros own intrd creation tools to make ltsp work.

LTSP would do better to implement library functions for each command, thus separating the actual command call from the functions. This way, the kiwi-ltsp function can source only the libraries and still make use of the ltsp-trunk shared code. The ltsp provided commands just become the default interaction method on the actual libraries, kiwi-ltsp is another implementation for the libraries.

For instance, from the kiwi-ltsp-functions.sh: enter_chroot looks a lot like the ltsp-chroot, and kiwi_ltsp_setup_sshkeys a lot like ltsp-update-sshkeys, and plenty more. Instead these functions should be embedded in upstream ltsp in such a way that kiwi-ltsp can use them from the ltsp libraries.

The kiwi-ltsp command can use this functionality directly by sourcing the ltsp library(ies). Right now it's implemented in such a way that the ltsp command use the kiwi-ltsp libraries.


 * Or the way we are doing at the moment is also fine, vendor specific ltsp-* tools' functions goes in ltsp-vendor-functions.

This way the development of kiwi-ltsp can focus on kiwi-specific things and ltsp development can focus on creating good cross-distro support.


 * That is exactly what is happening now, we are focussing on stuff that we need on openSUSE and those functions are available for anyone to copy/modify/use in whatever way they want, we will make kiwi-ltsp cross distribution including creating ltsp images using kiwi and openSUSE chroot/vm, most of the work is already done.