David Cantrell wrote:
Chris Lumens wrote:
<snip>
I see anaconda trying to get a very specific updates.img first and if that fails, try to get a progressively less specific image until it either finds one or runs out of options. So first it would try to get: http://wherever/f10/i386/updates.img Failing that, it tries: http://wherever/f10/updates.img, http://wherever/updates.img Once that fails, anaconda keeps going without prompting. As long as we use values we can determine from the .buildstamp or from the running system, I think this plan works out fine.Since an updates.img would be tied to a specific release and architecture, let's tie it to the anaconda version number rather than the Fedora version number. loader could build the URL to look for. Maybe something like: http://wherever/anaconda-11.4.1.58/i386/updates.img Or: http://wherever/anaconda-11.4.1.58/updates.img
I like this, +1
It might also be worthwhile to merge an arch-specific updates.img with an arch-independent updates.img file, since we could possibly have an update that affects ppc only and everything else is arch-independent. You would only make the ppc one when you fixed that bug, the other bugs would get rolled in to the arch independent updates.img.
Sounds to complicated, if we want to do a certain update only for one arch, why not put the other updates not only for that arch in to the same image ?
To me it seems much easier to solf this at update image build time, then in anaconda.
<snip> Regards, Hans _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
