"Jóhann B. Guðmundsson" (johannbg@xxxxxxxxx) said: > On 10/08/2013 09:02 PM, Bill Nottingham wrote: > >The anaconda installation image is made from the tree that it's composing > >from. As long as that's shifting underneath anaconda (file locations, > >NetworkManager interfaces, library bumps, LVM featuresets, etc. etc. etc.), > >considering anaconda behavior and code 'frozen' at branch time is > >extremely impractical when everything it depends on is not. > > I would assume not if we stick to the "GA tree" but more to the > point why exactly does the installation image have to be made from > the tree it's composing from? Anaconda relies on other components to do the heavy lifting - it uses NetworkManager to configure the network, if there are new LVM features, it relies on them being plumbed into the LVM stack (and into blivet, and into pykickstart) before those features can be used, it uses yum features & plugins for installation changes, and so on. So we *could* build an installation image based on the previous release's GA/GA+updates, but that would mean the featureset available during installation would lag the featureset of the main release by one cycle. That's a choice we could make, but I don't know that it's reasonable for our users. Matt asked about what logical roadblocks could be added if needed to support anaconda freezing earlier... I really do have a hard time seeing how this isn't "freeze NetworkManager, all storage utilities and libs, yum featureset, <insert other packages>" X number of weeks before anaconda branches. Which is messy, obviously. The installation image, if you're intending stability early, is essentially attempting to freeze a small live image 2 months before you freeze all the other live images. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
