Howdy, (1) Windows Installer / MSI Does anybody outside of Microsoft really like MSI? Wouldn’t a package format based on ZIP archives be a better cultural fit for open source software? I know MSI is the supported method for installing SxS assemblies. For the sake of discussion, let’s assume that isn’t an issue. What other advantages do you see in MSI? Are those advantages worth it?
MSI is just more that the supported method for installing assemblies. MSI provides us with a whole host of features that are built in to the OS that we can’t get without a lot of extra (and completely needless) effort--- MSI has a whole host of features that we can build on top of—not attempt to replicate. I’m not going to sit and list every one, but the more significant: - MSI files are recognized as installers by the OS already. Any other type of file would require us to have software on the system before the first package is installed. MSI provides us a method to transparently bootstrap that process and requires no prior knowledge on the part of the user. - MSI files provide transactional support around the installation of a package. Something goes wrong? Roll ‘em back. - a lot of enterprise management (Group Policy, etc) of software works around MSI files—a critical feature in rolling out software on thousands of desktops. - MSI is pretty easy to work with, and supports an extensible model for package metadata already. Why replicate? - MSI files are easily digitally signed, and again, the operating system knows what to do with that. - In spite of people’s incorrect opinion on the triviality of manipulating MSI files, they are actually pretty simple to pull data from, extract files and validate the contents. - zip files, on the other hand, are simply a container that while also fairly trivial to manipulate, really offers absolutely nothing required for package management and would mean we’d have to code up a bunch of needless conventions. (2) Shallow forks vs. upstream support I understand that shallow forks are needed to get started, but I hope the ultimate goal is getting CoApp adopted by as many upstream packages as possible. I have a dream that some day, I'll be able to grab the latest code for random open source projects and build them on Windows as easily as on Unix. Upstream support would be preferable, but even Ubuntu shallow forks pretty much everything. While the ideal world would have upstream projects shoulder the burden of maintaining Windows builds, it’s not very realistic. (3) CMake Have you looked at CMake (http://www.cmake.org<http://www.cmake.org/>)? There are several cross-platform build systems out there, and none has emerged as a clear standard. However, my observation is that CMake has gained the greatest acceptance. Could CoApp leverage CMake? Yes, I’m more than well acquainted with CMake. Unfortunately, it doesn’t solve any of the hard problems we’re tackling, it simply offers an alternative target for creating build scripts. Sure, CMake generates VC project files in the end anyway, but it’s not making things any easier, and for our purposes, offers little other than an extra indirection (with the possibility of incomplete functionality at build time) without accelerating our activities in the short run. G
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
