Dirk Stoecker wrote:
On Tue, 11 Sep 2007, Adrian Schröter wrote:
Regarding Windows support: how would you propose to specify package dependencies, given that no such support for this exists natively?
I have no real ideas about that. There do exist some approaches out there for that, but this is definitive the first thing what needs to get defined.
Yes, it will need quite some work to support this, I am sure. But imaging the new number of users, which we will attract :)
What about starting with cygwin-support?
Obviously much to be considered on this matter; I was thinking a bit about it, so I thought I would send my thoughts. If Windows support were to be offered, presumably the goal with that would be to facilitate porting/testing of Linux-based software onto Windows, rather than providing a big fat build farm for generic projects from the windows community :-) And obviously you'd need someone to pay for all those Windows licenses (or else you could try ReactOS and/or Wine?) There would need to be some meta-info related to each package for Windows. In the same way that you have debian.rules, debian.changelog and debian.control, you might have 'windows.build' and 'windows.package'. 'windows.build' would be some kind of file containing build-time information: how to unpack the sources, how to initiate the build, and a list of prerequisite packages and versions. As with RPM .spec file and Debian 'control' file, this stuff would be external to the sources. 'windows.package' would be some information about how the resulting package could be identified (eg where it can be found at the end of the build process), how it can be installed (in silent/unattended mode, specifically), how it can be uninstalled, and how it can be identified/checked (post-install checks). It would also contain a list of runtime prerequisites. To actually implement all that, you could write a miniature package manager. It could be given a .build or .package file as an argument, and could download and install the necessary dependencies then build the required package, and optionally report the results back to the Build Service (for the case that it was being run on a build host). This little package manager would also be useful for people wanting to use Windows software hosted on the Build Service: they would be able to download .package files (signed, presumably) and the installer would deal with the installation of the package including dependencies, with a configurable package repository URL or URLs. The package manager would have to optionally provide a windows 'service' that could be used for two-way communication with Build Service, eg to tell it when a virtual host had completed its boot-up and was ready to receive build commands. After the package manager had been written, the next thing would be to create some of the initial packages such as MinGW tools etc. They could be created as binary packages, just uploading the installer and the .package file somewhere. Cheers JP --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org