<!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>  > > >On Thursday 14 June 2007 09:15:30 Joel Andres Granados wrote: >> What I propose is a simple (I think its simple:) patch to address this >> issue. Give the user the possibility to add *one* >> directory to the tree. This directory contains whatever and is >> specified in the config file as extra_dir. >> Patch is attached >> comments greatly appreciated > >While possibly reasonable for one directory, as soon as you make this >capability, somebody is going to want multiple directories, or directories + >files, or.... > >I guess the point I'm trying to make is that there is already a method in >place to handle getting extra files/dirs into the tree, and there is even >more value to having them in package form to be installed on the system as >well. I really don't want to support N+ convenience methods for doing the >same thing as that's code duplication and easy places for bugs to popup, and >more places to have to change things in the future. > 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): - Find the RPM package that provides isolinux.cfg (I haven't found it yet) - Patch the source and create a new custom package - 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 - 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) 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. 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. My five cents :) --martin >-- >Jesse Keating >Release Engineer: Fedora > </BODY> </HTML>