Instead of talking about this right before every single release, let's talk about it when there's still time to do something with it? For a while now, we've been kicking around the idea of some sort of auto updates mechanism - a way to tell anaconda to just go and get an approved updates.img with important fixes from the release. Before I get started explaining this, I'd like everyone to keep in mind that this should be completely separate from all the mirrors, ISO images, etc. This is a whole other system in order to keep bureaucracy and complexity to a minimum. I've always seen this as nothing more complicated than a directory structure on a well-known website. anaconda assembles a URL, tries to fetch the updates.img from there, and continues through to stage2 regardless of if it works or not. Let me mention a couple issues I see with supporting this, along with how I'd plan on handling them: (1) Updates can support both arch-independent Python files, as well as shared libraries. We have occassionally made updates with libraries in them. Additionally, we support several releases at a time. Our directory structure should therefore support all these possibilities. 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. (2) Getting mysterious files from a URL without asking never goes over well. I'd prefer using updates=auto as the way to kick this off since then we're not doing anything without asking. To make it easier, we could put a new entry on the boot.iso menu that includes this option. (3) We need a process for deciding which bugs are important enough for inclusion, then making sure they get some testing before being published. I'm currently adding NeedsUpdatesImg to the whiteboard and putting the bug in ON_QA when I commit a fix for it. Is this sufficient? I'd like to keep the number of fixes relatively low or this gets very complicated. Should the fixes be committed to the release's branch? How do we give them enough testing? If the fix is not obvious, does that mean it's too complicated for an update and should only be dealt with in the next major release? (4) We'll need space to store these updates images that's guaranteed to not go away. I don't really know what to say about this one. Infrastructure stuff has always been mysterious to me. What am I missing here? It doesn't sound like very much work at all on the anaconda side of things. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
