starting Fedora Server SIG

Les Mikesell lesmikesell at gmail.com
Mon Nov 17 06:46:23 UTC 2008


Callum Lerwick wrote:
> 
>> 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.

That's a start for a single user to copy his machine.  I was thinking 
more of a way to publish the lists so that anyone could create the 
equivalent of a spin at the push of a button.

> The repo part is problematic because rpm doesn't keep track of what
> repos stuff came from.

That seems like a major design flaw, given an environment where it is 
impossible to pre-configure and coordinate repositories containing all 
possible packages - and expecting that situation to ever change seems 
unreasonable.

> 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.

You just need to propagate the non-standard ones.

> 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.

That should be up to the installing client.

> 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...

It's probably impossible to turn fedora into the sort of thing you'd run 
where you need predictability.  But the same scheme should work where 
the repositories are maintained to meed this user need.

-- 
    Les Mikesell
     lesmikesell at gmail.com




More information about the fedora-devel-list mailing list