Mailinglist Archive: opensuse-buildservice (287 mails)

< Previous Next >
Re: [opensuse-buildservice] Status: openSUSE Build Service
  • From: John Pye <john@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 12 Sep 2007 19:15:19 +1000
  • Message-id: <46E7AE27.1070102@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups