[Yum-devel] Considering yum/rpm for SDK distribution - seeking advice

James Antill james at fedoraproject.org
Wed Mar 3 16:54:17 UTC 2010


On Wed, 2010-03-03 at 10:10 +0000, James Aley wrote:
> 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.

 Personally what I would do is split your data into two sets:

1. Just binaries, or other non-changeable content.

2. Anything the developer might change.

...then put all of the first set into rpms, windows isntallers, dmgs,
etc. and have the second set as a git repo. (you could have the git
repo. in an rpm, even). Then all the git code for three way merging etc.
will just work.

-- 
James Antill - james at fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching


More information about the Yum-devel mailing list