Somebody in the thread at some point said: > Whatever. I'm in, either way. > I've been looking for something of that magnitude as an anchor project > in a long-term thing I'm currently conceptualising. > > You in, too? Or are you in more of a "peel me another grape" place right > now? I think this is a bit more complex than you may think. For example to be really useful, you need to be able to mix granular recipes. So you could take a recipe for someone's email setup from one place and someone else's recipe for secure webserving from another. Somehow it needs to deal with conflicts between the recipes (eg, one recipe specifies PHP4, another PHP5) and merging different config file contents from the different recipes (although /etc/blah.d/ is gradually helping on that front). If it is done right, one great thing that can fall out of it is no more monolithic versions (or spins) of Fedora. Just recipies you subscribe to that specify more or less proven / aged packages from Development for different tasks. Unlike Fedora legacy, which was a lot of work for no reward (and was undercut by the availability of later versions) there is no backporting, the originator of the recipe perforce updates his recipe to use packages that contain the fix and "publishes" it. That's what he would do anyway to deal with a security problem. But don't underestimate the difficulty of specifying how this should work in a complete way... implementing it aside. -Andy
