[K12OSN] flushing out my backlog... testing for version 4.1.1, followed by 3.2.0, then a 4.2.0 test build

[Eric Harrison]

On Fri, 1 Oct 2004, Les Mikesell wrote:

>On Thu, 2004-09-30 at 22:25, Eric Harrison wrote:
>> A good use of that time would be to make a complete
>> task list for generating a K12LTSP build from scratch. From fetching
>> the third-party packages, packaging LTSP, installer modifications,
>> and testing.
>
>Would it be possible/difficult to make all of the k12ltsp modifications
>into a configuration RPM that included only the template/scripts and
>dependencies for all of the other RPMs?  That would make it barely
>necessary to bundle it into a distro at all (but still handy...). If
>the scripts can accommodate the differences between distros you could
>use yum or apt-get to install k12ltsp-config into about anything
>redhat or fedora based. 

If you want a non-fedora/RH install, then the standard ltsp installer
is the way to go.

For the "enterprise" packages (a.k.a K12LTSP 3.2.0), I designed
everything around such meta packages (i.e. up2date -i k12ltsp-core).

I'm also thinking about making meta packages for K12LTSP 4.2.0 as
well, it is much quicker and easier to modify a meta package than
it is to change the package selection or upgrade behavior within
the installer. Meta packages also allow me to add new packages
by making them a dependancy to a meta package: when up2date/yum
sees the updated meta package it will know to grab the new
package as well. The flip-side is that meta packages are a bit
annoying at times. Probably a few good technical reasons to
avoid them as well.

But meta packages & distributing the K12LTSP-specific packages
unbundled are a low priority. The whole point of K12LTSP,
for the most part, is that is bundled all together.

-Eric