On 31 Oct 2000, at 22:21, Charles Steinkuehler wrote: > Dave Cinege has recently expressed to me his dismay regarding the way LRP > extensions and application specific disk images are being distributed: This hints towards what I call "data disks", including System Rescue and Network Tools. These are in reality just a 1.68M disk with a precompiled set of utilities in *.lrp form; these ARE available..... > So...I am working on formalizing a method to generate custom disk images > from a combination of a base image, additional packages, and 'addon' > packages. Dave has had support for addon packages for some time, but have > not been any tools to create or work with them, nor has there been an > explicit method for using addon packages to encapsulate customizations to a > disk image. "Support for add-on packages" I don't understand. *.lrp files are only *.tar.gz files renamed; just ungzip and untar and the files are added to the system - addon or not; nothing cares. It only cares when it looks for <pkg>.list or creates root.lrp, et al. > ---------------------------------------- > File System Updates > ---------------------------------------- > > To create truly easy to use application specific distributions, it is > usually necessary to modify a number of configuration files. To add > specific features, it may be required to add, modify, or delete existing > system files. All of this is possible using a slightly extended version > of the addon LRP package format. > > From a development standpoint, it is desirable that the addon packaging > system for customizing a disk image have the following features: > > 1) The ability to add new files > > 2) The ability to modify existing files > > 3) The ability to delete existing files > > 4) The ability to easily create and update the addon package, > preferrably from a running LRP system. > > The standard LRP packaging system provides features 1 and 2 (modifying > files is supported by simply overwriting them with updated versions). The lrpkg replacement I created ALSO very easily supports #4. Basically, you create a <pkg>.list *OR* a <pkg>.lis file (to support DOS 8.3 mangled filenames) in the directory where the package is to be created (typically /tmp). Then, all files listed in the <pkg>.lis (or <pkg>.list file) are added to the *.lrp, except, in the usual case, the *.list file itself. In this case, /var/lib/lrpkg has NO entries for this package, including /var/lib/lrpkg/packages. The package itself has NO special files AT ALL - except that, when using apkg to install it, you will receive a warning that the files contained in that package will be absorbed into other packages. This is also true during booting of an Oxygen system: the loading will have a "(abs!)" added to the package name if this is the case. > The existing LRP backup scripts do not, however, provide a way to delete > files already in existance on a running LRP system [...] True - and also true of apkg. However, you could crib this by creating a zero-length file or a commented file explaining the missing file. > To remedy this, I have created an addon.lrp package, which adds > support for creating addon packages to an LRP system, and extended > the format used for addon packages. I like your spunk, and ideas, but I don't think all this work is necessary. I've already put this together, and it requires NO extra files, virtually no extra work, and integrates seamlessly into the existing lrpkg and apkg - both which can install these packages I mentioned. Your way adds 5 or 6 new files, and requires additional support programs. > ---------------------------------------- > Future Goals > ---------------------------------------- > > Look into using CVS to archive the modified files required to customize > a disk image. > > Use 'diff' and 'patch' to create a more flexible addon package format? I have created a develop.lrp with the following programs (and their support libraries, etc.) in it: diff patch strace ltrace file ldd strip nm I find these to be very useful during debugging of binaries et al. -- David Douthitt UNIX Systems Administrator HP-UX, Linux, Unixware [EMAIL PROTECTED] _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel
