Am Freitag, 4. September 2009 05:35:05 schrieb John Pye:

Hi all

I expanded my page about Windows support for OBS as a build client on native Windows build-nodes. The idea is to build packages directly on Windows machines using MinGW, rather than using cross-compilers. Accompanying the concept is a concept for a package manager for Windows that would deal with dependencies in a way that interoperates with the usually 'standalone' installers common on Windows.

http://en.opensuse.org/Build_Service/Concepts/Windows_Support

Would appreciate any thoughts on this.

From my point of view the virtualized build system is the only way to go in the long term. Only that one would offer the needed functionality to build packages without the need to adapt the build system to support cross builds (which will anyway not work in all cases). I tried some time ago to use a wine wrapper inside of our build script to support windows builds. At that point of time, I was not able to get gnumake running inside of wine, but that is quite some time ago. Another option would be to try to use a prepare ReactOS image, haven't tried yet. I would like to avoid to use MS Windows for opensuse.org. It would be nice if we can support this as well, but using MS Windows would not allow the users to run secure local builds with "osc build", because we would not be allowed to distribute the image due to the license.

Also any thoughts on how such a thing might translate to Mac OS X, as well. Could it be possible for such a thing to work on both platforms?

When you want to invent a new package management, sure. However, I think it is better to support more native formats of the platform like .cab or .msi. This allows to use standard applications for Windows which allow to create a setup.exec from .cab or .msi files. And an own format would require the users to install another package management system first. The pure implementation time of a new package format into our OBS backend code would be quite low, if someone would find out how this format would look alike and adapt the build script for it. (Yes some bash script and one perl module). So, if someone is doing this job, either Michael or me can extend our OBS backend code relative fast for this (of course someone else can do it as well, but that needs quite some knowledge). The build script itself its modules (there are one RPM, one Deb and one kiwi) can be done easily, if you have have some knowledge about the windows format. This is were Michael and me are lacking the knowldege ;) thanks a lot for your work ! adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag 07 September 2009 02:01:40 schrieb John Pye: Hi,

...

...

I expanded my page about Windows support for OBS as a build client on native Windows build-nodes. The idea is to build packages directly on Windows machines using MinGW, rather than using cross-compilers. Accompanying the concept is a concept for a package manager for Windows that would deal with dependencies in a way that interoperates with the usually 'standalone' installers common on Windows.

http://en.opensuse.org/Build_Service/Concepts/Windows_Support

Would appreciate any thoughts on this.

From my point of view the virtualized build system is the only way to go in the long term. Only that one would offer the needed functionality to build packages without the need to adapt the build system to support cross builds (which will anyway not work in all cases).

I tried some time ago to use a wine wrapper inside of our build script to support windows builds. At that point of time, I was not able to get gnumake running inside of wine, but that is quite some time ago.

Another option would be to try to use a prepare ReactOS image, haven't tried yet.

I would like to avoid to use MS Windows for opensuse.org. It would be nice if we can support this as well, but using MS Windows would not allow the users to run secure local builds with "osc build", because we would not be allowed to distribute the image due to the license.

Perhaps the license issues could be overcome with a suitably high-level conversation with Microsoft by Novell? I doubt that one would be able to negotiate with MS that we're allowed to distribute a MS Windows based build system onto everybodies home computer with osc build ;-)

And, on the other hand, I think we should try hard to push in the free software direction and work with alternatives. ReactOS is a great initiative, and maybe we can ask them for help?

...

The pure implementation time of a new package format into our OBS backend code would be quite low, if someone would find out how this format would look alike and adapt the build script for it. (Yes some bash script and one perl module).

So, if someone is doing this job, either Michael or me can extend our OBS backend code relative fast for this (of course someone else can do it as well, but that needs quite some knowledge). The build script itself its modules (there are one RPM, one Deb and one kiwi) can be done easily, if you have have some knowledge about the windows format. This is were Michael and me are lacking the knowldege ;)

My thoughts on all this are that RPMs are great (especially coming from a Linux background), but they're not really what end-users demand. On Windows, end-users demand MSI or .EXE installers, and if there is any package management, then it has to happen automatically from within that installer. MSI does not support dependencies which makes it hard but not impossible for the build environment setup - we probably have to go a "install all"-way.

For the bundling of the user downloadable packages MSI also could only be used if we also follow the 'put everything in' approach which seems to be quite common on the platform. To create MSI's it seems to be recommended to use a opensource toolkit called WiX. It is driven by Microsoft and written in C#, see http://wix.sourceforge.net/ and a tutorial here: http://wix.sourceforge.net/tutorial.html It comes with command line tools and uses a XML file config file from which a MSI package (or program?) is compiled. Sounds pretty much how we like it, except some details maybe ;-) There is a pretty active community with mailinglists. We also could ask there for help. regards, Klaas -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

As i said, i have already wrote an OSC client who run really nice under Windows, after what i have started to write RPM management for Windows OS (also for other OS), a preview can be found here : http://surfzoid.free.fr/freevbsoft/MonoRPM/MonoRpm.2009.02.07.tar.bz2 The goal should be to have an RPM manager in the linux style (Add media from repository, install uninstall RPM from those media or locally ....) In my idea i took only the way to install RPM who provide mono/.Net program, because they are already cross platform, Everaldo started to work on the creation side of RPMS. 2009/9/7 Adrian Schröter :

Am Montag, 7. September 2009 09:11:10 schrieb Klaas Freitag:

...

Am Montag 07 September 2009 02:01:40 schrieb John Pye: Hi,

...

...

...

I expanded my page about Windows support for OBS as a build client on native Windows build-nodes. The idea is to build packages directly on Windows machines using MinGW, rather than using cross-compilers. Accompanying the concept is a concept for a package manager for Windows that would deal with dependencies in a way that interoperates with the usually 'standalone' installers common on Windows.

http://en.opensuse.org/Build_Service/Concepts/Windows_Support

Would appreciate any thoughts on this.

From my point of view the virtualized build system is the only way to go in the long term. Only that one would offer the needed functionality to build packages without the need to adapt the build system to support cross builds (which will anyway not work in all cases).

I tried some time ago to use a wine wrapper inside of our build script to support windows builds. At that point of time, I was not able to get gnumake running inside of wine, but that is quite some time ago.

Another option would be to try to use a prepare ReactOS image, haven't tried yet.

I would like to avoid to use MS Windows for opensuse.org. It would be nice if we can support this as well, but using MS Windows would not allow the users to run secure local builds with "osc build", because we would not be allowed to distribute the image due to the license.

Perhaps the license issues could be overcome with a suitably high-level conversation with Microsoft by Novell?

I doubt that one would be able to negotiate with MS that we're allowed to distribute a MS Windows based build system onto everybodies home computer with osc build ;-)

Right, me too.

...

And, on the other hand, I think we should try hard to push in the free software direction and work with alternatives. ReactOS is a great  initiative, and maybe we can ask them for help?

...

...

The pure implementation time of a new package format into our OBS backend code would be quite low, if someone would find out how this format would look alike and adapt the build script for it. (Yes some bash script and one perl module).

So, if someone is doing this job, either Michael or me can extend our OBS backend code relative fast for this (of course someone else can do it as well, but that needs quite some knowledge). The build script itself its modules (there are one RPM, one Deb and one kiwi) can be done easily, if you have have some knowledge about the windows format. This is were Michael and me are lacking the knowldege ;)

My thoughts on all this are that RPMs are great (especially coming from a Linux background), but they're not really what end-users demand. On Windows, end-users demand MSI or .EXE installers, and if there is any package management, then it has to happen automatically from within that installer.

MSI does not support dependencies which makes it hard but not impossible for the build environment setup - we probably have to go a "install  all"-way.

I was told that there is something in .msi and .cab where you can somehow require others. And .msi should be extensible to an own, obs-properitary provides/requires system at least.

...

For the bundling of the user downloadable packages MSI also could only be used if we also follow the 'put everything in' approach which seems to be quite common on the platform.

To create MSI's it seems to be recommended to use a opensource toolkit called WiX. It is driven by Microsoft and written in C#, see   http://wix.sourceforge.net/ and a tutorial here:   http://wix.sourceforge.net/tutorial.html It comes with command line tools and uses a XML file config file from which a MSI package (or program?) is compiled. Sounds pretty much how we like it, except some details maybe ;-) There is a pretty active community with mailinglists. We also could ask there for help.

regards, Klaas

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- I have no special talents. I am only passionately curious Sent from Paris, France -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org