>> I can see there's going to be a lot of talking about updates images. >> Since we are absolutely going to be preserving this behavior in our >> loader rework, perhaps it's worth moving all that off into a new thread >> anyway. >> > I'm suggesting the use of the updates repo for the URL, as that is the one > that would be sync'd by advanced users, to keep things updated in their > home mirrors. Once I download the original tree for a release, I don't try > to re-sync that one, the content shouldn't change, that is what updates > repo is for. A new thread would be the best, I'll leave any more talk for > that one. The updates repo isn't guaranteed to contain the entire package set, though. It's just going to have packages that have published updates since the final release. So we can't really use the updates repo for the URL. What I'd really like to do is have a checkbox in the repo selection UI (tasksel.glade in case you're curious) that enables the updates AND check that box by default. I know we've threatened this in the past. > OK, should I be thinking that stage2= will be the replacement for method= > for stage1? I'm getting that feeling, just want to be sure. Yes, though not really a complete replacement. The final goal is that stage2= points to just the stage2.img file, while method= points to just the package repository. Perhaps at that point we rename it to repo= to avoid confusion? Don't know quite what to do here yet. >> Only somewhat relatedly, I'm going to be investigating adding a hook for >> running gdbserver during the loader. The idea here is that if you >> provide a second initrd with gdbserver in it, loader will detect that >> and run it in case of emergency. Then we have better debugging >> capabilities without adding lots of code that everyone ends up running. >> You know, since you mentioned debugging and all... >> > Sounds interesting, how would you go about the second initrd.img? Just in > general, a pointer to a wiki page would be enough for me. If you PXE boot, you can specify multiple initrd lines and they'll all get combined together to work. I'd just make a second initrd containing gdbserver and add a new target for booting with it. For other booting methods, I don't know right now. I'm sure we can figure something out for CDs and the like. > I'm getting the feeling that if it's not an iso type of install, then > support for the that which maybe used for a custom tree on a hard drive or > via nfs is unwanted. I understand that from a support point of view, just > that limits outsiders(me) from playing around with the install tree. Having > to do a re-make of an iso for something like testing changes to comps.xml > makes me a bit ill. Could just be a "use at your own risk / unsupported" > option with the patches welcome warning... Guess I'll just use net based > installs to test my custom repos then. Hm, no, it's not my intention to remove all the support for customizing ISO image installs. I do want to keep around the implicit updates.img locations so you don't have to rebuild images, as I agree that's a total pain. We just need to think up good ways to support these customizations without creating a giant mess. > I suppose I'll have to get used to using just the updates.img, that does > have support for using of a custom comps.xml file for the anaconda repo? > That, and the repo editor would make a great tool. Sorry, I have not kept > up with that part of the code, or can the repo editor make use of a custom > comps.xml file? I toggle some of the default/options, or does that fall > under unsupported? Yeah, probably best to get used to using updates.img. You're looking to have a new comps.xml file in the updates.img that overrides the one in the installation repo? I don't think we support that in RHupdates or updates.img right now. Anyone else want to take a stab at answering this part? As for the modified repo editor... I'll be posting my UI mock up for that later today I think. I want to make sure the list stays lively, after all. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
