I'm Shyam from India. I have a decent amount of experience in application packaging and maintenance of OSS components in mixed environment in both native and emulated (cygwin).
What's enthralling to me is - coapp aims to do what the company I worked 2 years ago, intended to do that time ( and failed ). I'm outlining what I did, when we had no one sort of rules in place. I worked for the India Development center of a popular company that specializes in providing business-ready open source software solutions. One of our flagship products was called software factory as it built small ISV's build infrastructure stacks like WAMP ( windows, apache, mysql, php ), WAPP ( the same with PostgreSQL ) and Java stacks based on tomcat along side integrating your new web 2.0 app. Our business model was based on delivering support thru these stacks. ( Offering custom builds with community patches, patches for 0 day exploits, and a single update channel, etc. ) Our build system was based on gentoo's portage. The builds for linux were a walk in the park as we leveraged on community ebuilds. For Windows, it was quite a challenge., we made small changes to portage system and made it run on Windows. As most of the infrastructure components like Apache, PHP, etc. gave the VS Solution files, which made our jobs easier to write custom ebuilds.However, for other components, we had to write our own ebuilds and also create VS solutions. Mind that certain components like libjpg still need VS6 to compile and wont compile in VS7 or upwards. Our toolchain had - VS6, VS7 and VS8. At that time, VS7 was out defacto compiler, VS8 was experimental and VS6 was used for older incompatible components. Unlike coapp's vision, we decided to follow the linux way of deployment. All our applications were deployed on one directory inside the root drive. This directory had a directory structure similar to linux - like /usr, /var, /lib, /opt, /etc. All the high level infrastructure components like Apache, PHP, MySQL reside inside /opt. The configs are inside /etc. All the shared libraries lie inside the /lib., etc. Since it is windows, integration along with windows services, etc. were put in place. Ofcourse, we also had our hacked version of portage inside. This helped us leverage it for update. We pointed portage's config to point to our servers, which delivered tested components as update. Of course the config. backup and restore was a bit tricky - but it worked for most people. Our sales team had nearly 1800 ISV's sign up and use this service and generate their custom stacks with their components, however, recession had set in by then and I joined another company and rest is history. coapp is interesting, but I'm wondering what its complete intentions are: - whether it was it to port every OSS app and make it runnable in windows. ( something like what Mac Ports or Fink does ) or - whether it is interested to maintain certain components ( if, yes, what are those and what is the criteria, etc. ) Pardon my ignorance if the above were already answered - Regards Shyam
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
