On Mon, Jul 22, 2013 at 04:30:32PM +0200, Miloslav Trmač wrote: > How do I package and ship an application that depends on two or more > stacks (e.g. uses a database, has a web frontend and perhaps also a > local GUI) if the stacks the application depends on can have > overlapping and therefore probably (necessarily?) conflicting > software, different lifecycles and packaging methods? I'm not suggesting a crazy free-for-all. If you have an application which depends on multiple stacks, you would want to select one technology for all of those stacks -- OpenShift cartridges, or Software Collections, or Fedora Formulas. If you want to use a cartridge for one and a software collection for the other, I don't think there's any expectation that this would work. This is also why I had "environments" as a higher ring in earlier versions of the slides. When you're making your development or package-and-ship decision, you want to be thinking about the environment in which it will run and then the implementation technology decision comes from that. > > This is a special bubble within Ring 2. In fact, on Day 0, it still is > > _all of_ Ring 2. The name here is mean to evoke Creative Commons; we can > > discuss other possibilities too, of course. > What happens when a RPM (presumably) package from Fedora Commons > depends on infrastructure that decides to move to a stack and stop > using RPM? The same thing that happens in Fedora now when someone decides to stop maintaining an RPM. > > In the future, a namespace approach > > could even make /usr/bin/python be Python 3 for some processes but not for > > the core OS. > (Namespaces are an administration nightmare because paths suddenly > don't mean what they seem to mean.) That's why "in the future". That particular idea is something some people are exploring but which needs a lot of details worked out. I think we should encourage the exploration, though. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
