On Thu, 2012-11-08 at 18:15 -0800, Adam Williamson wrote: > > Again, this isn't an accident, it's a very deliberate plan. One of the > whole points of the Fedora philosophy is that we're supposed to share > and reuse work and code as much as possible. We're not supposed to write > five independent versions of everything at all. The fact that anaconda > team had to maintain their own loader (which did pretty much what dracut > does), their own partition code (which did pretty much what parted does) > and their own network code (which did pretty much what NetworkManager > does, only not as well) was a problem, not an advantage. It meant we > were duplicating a whole bunch of effort to get inconsistent results. > anaconda team was wasting time maintaining a bunch of network code that > wasn't as good as NetworkManager in the first place (ditto for the other > two examples). > > The overall strategy of the anaconda team has been to try and reduce > their maintenance burden; they'd reached a point where they were almost > running full tilt just to stand still - they had so much unique code to > maintain that it took almost all their resources just to keep it working > and up to date. They couldn't work on actually improving anaconda, it > was the best they could do just to keep it at the level it was at. > > So they deliberately went out and aimed to reduce that burden, and using > existing code like dracut, NM and parted was just a part of that plan. > newUI is another part of that plan - it's a lot of work now, but the aim > is that it's less of a maintenance burden than the old UI code when it's > done. The ultimate goal is that an anaconda team with the same resources > will be able to devote much less time to just keeping a giant codebase > working, and more time to enhancing a smaller codebase. > > So no, our installer absolutely is not independent from the rest of the > distro, it's not intended to be and it shouldn't be. It's deliberately > designed to reuse components of the distribution as much as possible, > and the goal is if anything to increase this over time, not decrease it. > The maintenance burden of adjusting to changes in those components it > depends on is non-zero - which is where we came into this side track - > but that's not a problem. It's non-zero, but it's much lower than > duplicating all those components from scratch, only worse. I agree 100% that it is right for the installer to use the system infrastructure for the things it needs to do. That is a much needed and very welcome change. I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Maybe that is a design discussion for a different installer, anaconda has always been a 'fat' installer, and it doesn't look like that is going change. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
