Hi, Thanks for the responses, very helpful. Yes, quite right... I glossed over some important information there.
The problem with distributing the whole SDK as single installers (appropriate formats for each platform) is that it's an entire operating system, made up of ~140 package, each of which contain maybe 10-20 components. "Dependency hell" comes as standard, also we need to distribute each package as source and pre-built binary for a couple of architectures. If you put yourself in the shoes of a developer working on shipping a phone based on our OS, monolithic installers are not your friend. One would need to clean and roll-back individual components, see what source corresponds to the installed version, exclude some components from updates (to substitute for a modified, built from source version?), etc. Imagine if, every two weeks we released an installer that would effectively re-image this poor guy's development environment... Well we pretty much do that now with some big zip files, and he's quite understandably not thanking us for it. It seems a very similar problem, to me at least, to package management. So I was thinking that a better solution might be that we distribute a small tools package as an initial download (as you suggest, msi, dmg, rpm), including a package manager client of some sort that will pull down the required SDK packages for the developer, then help them to clean up things they've changed and pull in new version of select (if necessary) packages later. That's what lead me here. Does my story make more sense now? Thanks again for your time! James. On 2 March 2010 20:47, Seth Vidal <skvi...@fedoraproject.org> wrote: > > > On Tue, 2 Mar 2010, James Aley wrote: > >> Hello, >> >> Background: I work for the Symbian Foundation. We're a non-profit that >> over-see the Symbian operating system. This is an open source (EPL) OS >> for mobile phones, primarily used by Nokia, Sony Ericsson and Samsung, >> or anyone else that wants to. My team is "technology management", we >> work on the platform road map, sourcing contributions, etc. >> > > interesting. > > >> To me, the obvious solution seems to be package management, as I'm >> very much against reinventing the wheel and can see projects like yum >> have already solved some common problems brilliantly. I have a few >> concerns though, so I'd really appreciate if anyone can answer any of >> the following (with respect to yum?) or generally offer advice if you >> think we're barking up the wrong tree! >> >> * Given that this is an SDK we're distributing, I think the package >> manager's database should work with a "sub-environment" on the >> developer's machine, i.e. not touch anything that belongs to the host >> OS and work from a configurable root environment variable. Is that >> already supported in yum? Or, does it sound like a bad idea generally >> speaking? > > rpm (what yum uses underneath) doesn't have a good way of referring to > multiple databases for installed dep resolution and yum doesn't implement > anything like that either. So if this is a requirement it's pretty much a > nonstarter. > > Now - if you're just talking about being able to run things from chroots - > that's a different ballgame. > > > >> * We have a commitment to support all major platforms. Would we be >> able to port yum to Windows/Mac trivially, or should we forget it? I >> sense headaches in creating RPMs that even make sense on a Windows >> environment, but the limited scope of installing packages to the SDK >> environment only might help overcome that? > > making rpms which make sense on windows will be complicated. Now, rpms for > mac osx already exist and are used. > > > >> Also, any recommendations for documentation I should look at would be >> great. > > I guess I'm bit unclear what the use case is for the sdk deployment? It > seems more likely you would want to prepare rpms for the linux systems, > windows installers for the windows env and dmgs for the macs. In much the > same way firefox, for example, does now. > > Rather than trying to get all your users to use your tools it seems like it > would be vastly less effort for you to use the tools your users' systems' > provide. > > does that make sense? > > -sv > > _______________________________________________ > Yum-devel mailing list > Yum-devel@lists.baseurl.org > http://lists.baseurl.org/mailman/listinfo/yum-devel > -- James Aley, Technology Specialist Symbian Foundation. www.symbian.org _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
