[K12ltsp-list] Repackaging ltsp for Red Hat distribution

[Jeff Johnson <jbj JBJ ORG>]

OK, now that I have a little experience with K12LTSP packages, I
can see a couple of issues that are going to need to be resolved.

The first, and most important, issue is that ltsp packages are
mostly tarballs of binaries, not traditional sources/patches.
This can lead to a number of problems including
	- updating/maintaining individual binaries
	- customizing iinstallations for specific purposes
as packages like lts-core are all or nothing (i.e. installed or not).

In order to address this issue, I've taken the lts_core-2.09pre1.tgz,
and recreated the /tftpboot/lts/ltsroot client tree from source components.
I've packaged this in a single humongous (46Mb) lts-2.09pre1-0.1.src.rpm
that uses rpm to build the following src.rpm's
	Source11: busybox-0.60.0-0.2001_08_21.src.rpm
	Source12: bash-2.05-9.src.rpm
	Source13: strace-4.3-2.src.rpm
	Source14: e2fsprogs-1.22-3.src.rpm
	Source15: portmap-4.0-38.src.rpm
	Source16: ypbind-1.8-1.src.rpm
	Source17: sh-utils-2.0.11-5.src.rpm
	Source18: util-linux-2.11f-8.src.rpm
	Source19: SysVinit-2.78-18.src.rpm
	Source20: MAKEDEV-3.2-3.src.rpm
	Source21: open-1.4-12.src.rpm
	Source22: zlib-1.1.3-23.src.rpm
	Source23: ncurses-5.2-12.src.rpm
	Source24: glibc-2.2.4-5.src.rpm
and then installing the freshly built binaries out of the sub-builds.
I have the src.rpm if anyone is interested.

This approach to packaging ltsp will "work" for Red Hat (i.e. we
can debug and support the binaries efficiently), but the packaging
is more than a little surprising, unwieldy and awkward. One of the
problems that I can already foresee is, if I continue down this pathway
and include (by rebuilding) the components necessary to reconstitute
the now separate tarballs
	lts_localapps-2.09pre1.tgz
	lts_x_core-2.09pre1.tgz
	lts_local_netscape-2.09pre1.tgz
I'm going to find myself rebuilding glibc, mozilla and XFree86 within
my lts package in order to build a client lts tree. Ick ...

Other problems are more subtle. From looking at Eric's patches to
the lts-2.08 tarballs, I see that support for sound and usb (and probably
more) have been added. Adding new features like this is bound to happen
sooner rather than later, and there's no clear call on what's right and
wrong, only what is.

Other, rather nerdy, nit-picks come from vetting the components in
lts_core-2.09pre1.tar.gz:
	1) bash is statically linked, busybox is not.
	2) env/id executables are included separately, not
	   as links to (possibly patched) busybox.
	3) choice of devices like agpgart, and number of tty's etc
	   is arbitrary.
	4) other glibc libraries are not included, and existing libraries
	   are included without the usual symlinks.
I don't mean to criticize at all, I'm just pointing out that there are
subtle hidden decisions in what is included and what is not with ltsp
tarballs, and guidance regarding the Right Thing To Do is mostly unavailable.

The other lts packaging issue is the multiplicty of kernels with hardwired
ethernet drivers. Can't a single kernel loading modules from an initrd
be used instead? I suspect the answer is "Yes, but ..." and the details
will have to be worked out.

So, here's a suggestion for managing the lts client prototype tree:

rpm has always had a --root option to install packages within a
chroot. Can't existing distro packages be installed into a
/tftpboot/lts/ltsroot chroot environment with its own database?
Yes, there are a handful of symlinks pointing back to per-client
/tmp and /proc mount points. There are a couple of ways to handle
that AFAICT.

Opinions?

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj jbj org	(jbj redhat com)
Chapel Hill, NC