Allan Lyons wrote: > Hi, > > I was working on a patch to distribute the files between initrd and > the network share differently. I need to clean it up a bit yet, but > I thought that I would ask to see if there is any concensus about > where the different types of files should go. > > Obviously, files that are required before the network share is > mounted have to be in initrd. > > My current thoughts on the other ones are that files that need to be > compiled and therefore could be specific to the linux environment > might as well go in initrd. On the other hand, files such as > nt5x-install, etc. that are more likely to be adjusted should go on > the network share to make them easier to hack. > > Does this make sense to you?
I personnally *really* prefer to keep boot image files (bzImage and initrd) as tiny as possible. For a given file on a network share, It takes only space on hard drive; no more, especially if unused. The same file inside a boot image: its content has to be totally transfered, since they are part of boot images (even compressed). Also, if boot images become huge, it may be trouble on system with few MB of memory (since have to "mount" it in RAM). On a network share, you don't have the same constrains in term of space. From a maintenance/devel perspective, It's really a lot easier to just have to patch a file on a network share than have to first regenerate boot image files just to test/check the modification and reboot. Most of time, you don't even need to reboot to test, just relaunch a script or a command (at least for basic testing). I would prefer that linux specific stuff go into /linuxaux in such a case. On my side, I will prefer that we provide first a template mechanism or default value in order to better use the nicely scripts provided in install/scripts/ . For instance, I use them but first step is to customize content of install/scripts/ : I don't have Windows 2000 here, so what's the use to download its related patches ? I also have different requirements related to core installation, don't care about app X or Y: don't want to download related files, do not want that they appear in application/package list to deploy post-OS, and so on. So I clean this folder content ... and have then to integrate updates from U. project on these files: deal with which I remove, which I patched, why the use of this particular file, etc. my $0.02 Pierre Bourgin ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ unattended-devel mailing list unattended-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unattended-devel
