(Finishing and sending the email I forgot to send this morning...) On Tue, Jul 05, 2011 at 09:56:40AM +0300, Alexander Todorov wrote: > +1 for the idea. Thanks! :) > This can be useful to QA teams in scenarios where the base > install image is the same and various packages are then added and tested. Yes, that absolutely makes sense. Another example would be grid deployments -- blasting out identical nodes with as little overhead as possible. (This is a one of the cases where the multiple-archive scenario I suggested makes sense.) Creating grid nodes is a particular case where you often want to be certain you are running exactly the same image. > Could also be useful for backups/system restore functionality. I hadn't really been thinking of that; there are probably better tools for that job. Maybe you have a backup/restore flow that I haven't thought of where it makes more sense than I'm assuming? That is tangentially related, though, to why I was considering cpio as well -- use some tool that generates an exact list of files to archive (normally: packaged files, plus a list of unpackaged files), then use cpio to create the archive, since tar doesn't have an --include-from= command-line option. That might break selinux though -- the first time I created a tarball for testing, I forgot to use --selinux on the tar command line and couldn't log in until I booted with autorelabel. I don't know if cpio has been extended with selinux support; my quick google search indicated that it hasn't been but I'm sure people here know better. But then, I guess that not everyone uses selinux, and if you really want to use cpio and are using selinux, you could just add a .autorelabel file at the root of the archive and at the expense of a relabel operation, the system would be usable. That cuts down on the speed benefit of installing an archive, but for cases where that's not the primary goal, maybe that's OK. Anyway, I'll look at multi-archive support and come back with code to talk about. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
