Re: archive-installer backend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

does this take into account that we have support for adding additional repositories?

I was thinking about the backend changes needed to support installing from multiple tarballs (software bundles) and one issue we have to solve is merging rpm metadata (or at least creating them at the end of the installation) so the system has proper information about everything.

--
Martin Sivák
msivak@xxxxxxxxxx
Red Hat Czech
Anaconda team / Brno, CZ

----- Original Message -----
> (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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux