| |||||||||||||
|
| |||||||||||||
RespinsRespinsPosted Dec 26, 2006 6:36 UTC (Tue) by markhb (guest, #1003)In reply to: Respins by mattdm Parent article: Announcing the Fedora 6 Zod live CD and live CD tools
The issue with FC6, though (and I assume this is what the gp was referring to) is that Anaconda misidentifies single i686 CPUs as i586 when choosing the kernel, and I imagine that the same CPU signature would be grabbed from updates. I am not sure what the performance hit is, if any, but I still think it's embarrassing and wrong enough that it should have been treated as a brown-paper-bag bug and the CD1 and DVD images respun.
(Log in to post comments)
Respins Posted Jan 4, 2007 4:44 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] It might be worthwhile for the Fedora project to plan on doing a couple of ISO respins. Once a few hundred commonly used packages have updates, and the next major release is still months away, it can actually save bandwidth on the mirrors to have more-current ISOs, because all those sides then avoid updating hundreds of packages with yum. It's also nicer for people who don't have high-speed access, they can get a more up-to-date CD by mail.
Respins Posted Jan 4, 2007 23:34 UTC (Thu) by pjones (subscriber, #31722) [Link] Well, if nothing else, this is at least fairly trivial to work around with an updates.img or (if you're installing from NFS) the "RHupdates" directory.
Make a directory named "RHupdates" in the top level of the install tree on your nfs server (i.e. the same directory that holds "GPL", "eula.txt", and the "Fedora" subdirectory), and in it put packageSack.py (from yum's .src.rpm) in it.
Voila, when you install from that tree using nfs it will work correctly.
|
|
||||||||||||