<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.14">
<TITLE>RE: pungi used to create CD that includes a kickstart file [PATCH]</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>><BR>
><BR>
>On Thursday 14 June 2007 09:15:30 Joel Andres Granados wrote:<BR>
>> What I propose is a simple (I think its simple:) patch to address this<BR>
>> issue. Give the user the possibility to add *one*<BR>
>> directory to the tree. This directory contains whatever and is<BR>
>> specified in the config file as extra_dir.<BR>
>> Patch is attached<BR>
>> comments greatly appreciated<BR>
><BR>
>While possibly reasonable for one directory, as soon as you make this<BR>
>capability, somebody is going to want multiple directories, or directories +<BR>
>files, or....<BR>
><BR>
>I guess the point I'm trying to make is that there is already a method in<BR>
>place to handle getting extra files/dirs into the tree, and there is even<BR>
>more value to having them in package form to be installed on the system as<BR>
>well. I really don't want to support N+ convenience methods for doing the<BR>
>same thing as that's code duplication and easy places for bugs to popup, and<BR>
>more places to have to change things in the future.<BR>
><BR>
<BR>
Having everyting packaged is a very nice and pure approach, but IMHO it might not be user friendly enough for people to create appliances. To package everything requires a different skill set. Consider this: In order to have Anaconda start with a kickstart file, the file isolinux.cfg needs to be modified (add the kickstart kernel parameter, change the splash screen). In order to package this, I would have to go through these steps (I think):<BR>
<BR>
- Find the RPM package that provides isolinux.cfg (I haven't found it yet)<BR>
- Patch the source and create a new custom package<BR>
- Substitute the original package with the new one in the comps file, so that the original one does not get loaded as a mandatory package<BR>
- Maintain that custom package going forward (It needs a different name so that yum update does not load the original one back, but that could mess up other packages that depend on it - don't know yet)<BR>
<BR>
The alternative seems much easier: Copy the altered isolinux.cfg file into the tree after buildinstall. Although I do agree that packaging all this is the cleaner approach.<BR>
<BR>
To create an appliance pungi needs to offer the ability to customize the stage 1 installation process. The stage 2 installation process can then be customized using a regular kickstart file. Althoigh I haven't yet gotten to customizing the stage2 graphics and might run into other issues there.<BR>
<BR>
My five cents :)<BR>
--martin<BR>
<BR>
<BR>
>--<BR>
>Jesse Keating<BR>
>Release Engineer: Fedora<BR>
><BR>
</FONT>
</P>
</BODY>
</HTML>