Tor Lillqvist wrote:

> Hello,
>
> I have been doing some initial small steps to make RPM work on
> Windows. (Well, a subset, just package management, definitely not the
> rpmbuild aspect for instance.)
>
> I have done this using the RPM 4.7 codebase. (Without bothering with
> any upstreaming attempts, as there isn't any real upstream for RPM 4,
> is there? I wasn't even aware of RPM5 until I stumbled upon it
> yesterday...)
>
> Would you eventually consider accepting such patches into the RPM5
> codebase? Of course the intent is that the patches would be as
> nonintrusive as possible, with a minimal amount of ifdef cruft.

Some of the changes were released two years ago* for Cygwin support,
such as macros for file extensions and other such Windows things.
They would probably need updating for RPM 5.2, rotted a bit since ?
But going MinGW32 (like MSYS) sounds like brave new terroritory...

* says http://rpm5.org/pressrelease.php

> I don't really have a clear design plan or roadmap, basically I just
> tinker a bit now and then and see what it starts to look like. One
> obvious difference between how RPM would work on Windows compared to
> Unix is that there can't be any hardcoded paths. Even though a RPM
> package contains hardcoded absolute paths, when the package is
> installed the paths need to be remapped to be relative to the
> installation prefix it is being installed in. Whether this should be
> coupled to some existing RPM concept (the --root option comes to mind,
> but it isn't really the same thing) or not I can't say yet.

I don't think there was much done for Windows or even for Mac OS X,
only for Cygwin and Darwin. So RPM is still a Unix package manager,
even if portability was much improved with the RPM 5.0 release up.
And the paths were still hardcoded, but relative to the Cygwin root.

> The cross-compiled packages for Windows in the openSUSE Build Service
> that contain Windows binaries are from RPM's point of view "noarch",
> as the idea with them is that they are installed on a Linux host. Then
> using some unspecified mechanism an install set for some app is built
> and copied to and installed on actual Windows boxes. I think I like to
> keep it that way, i.e. they will continue to be "noarch" from a RPM
> point of view, and some other more or less standardized convention
> (like a prefix of the package name, as now, or something) will be used
> to identify that a package actually contains Windows binaries. This is
> so that the same cross-compiled rpm package can be both installed on a
> Linux host, *and* then eventually on a Windows host if RPM on Windows
> becomes a reality.

There is a "rpm2nsi" still around somewhere, that constructs a
Windows setup.exe installer* given an RPM. It doesn't handle any
dependencies or database, but is sometimes useful. (There is a
matching "rpm2pkg" for Mac OS X, that makes an Installer package.)

* using http://nsis.sourceforge.net/

--anders


PS. There is a Windows branch of Smart, if you need a meta-pm...
     Was done for use with the winlibre summer of code '09 project,
     but I'm not sure if their new "wpkg" ever made it anywhere ?
     https://code.launchpad.net/~afb/smart/windows (winlibre.com)