starting Fedora Server SIG

[Callum Lerwick]

On Fri, 2008-11-14 at 13:32 -0600, Les Mikesell wrote:
> Bill Nottingham wrote:
> > Seth Vidal (skvidal at fedoraproject.org) said: 
> >> Curiously enough you could make a fedora spin repodata now with  
> >> mergerepo and then modifyrepo to add the spin-specific comps and  
> >> provider-selection metadata all pointing back to 'everything' for the  
> >> actual packages.
> > 
> > Or (sick thought of the day) have a package that drops a unchanging
> > repo definition, comps file, preferred app, metadata all on the local
> > disk, to define defaults for that install.
> 
> I'm still conviced that what is needed is a simple way to export a 
> complete installed list from any working machine along with repo and 
> version information that the machine repeating the install can use or 
> ignore.  That way there is no guesswork in the installer and it works 
> the same for a spin providing some extra stuff in  an additional repo 
> and a local shop with local packages in a local repo.

So develop one. You can start with:

rpm -qa --queryformat %{NAME}-%{version}-%{release}.%{arch}\\n | sort > packagelist.txt

Then on the destination:

xargs yum install < packagelist.txt

There, you're 90% there with just two trivial lines of shellscript.

The repo part is problematic because rpm doesn't keep track of what
repos stuff came from. Also, how do you tell the destination machine to
use the same repos? I suppose you could just serialize the entire yum
configuration from the source machine, and dump it on the destination.
Brute force but effective.

Then there's the problem of what to do with differing archs. If they're
both x86_64, you probably want the multilib configuration mirrored too.
On the other hand, if the destination is *not* the same arch as the
source, it's going to barf unless you strip out the arch first.

The fact that Fedora doesn't keep old packages around is going to cause
you problems as updates come out the firehose, unless you maintain your
own Fedora mirror that you control, which you really ought to be doing
if you're doing mission critical deployments...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081116/5da1feba/attachment.sig>