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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
