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.

The work was done in the cross-compilation framework in the openSUSE
Build Service. Current status: it builds, but doesn't really do much;)
I.e., it is very much an experimental work in progress. I have only
spent some weekends last year on it.

(If somebody is interested in the diffs used, check out the
mingw32-rpm source rpm at
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.0/src/
).

Yes, a lot of the POSIX syscalls like chroot() have no equivalence on
Windows, so a lot of stubbing out with debugging printouts is used,
just to make it build and see whether such missing functionality
actually would be needed in the subset of RPM functionality that would
be implemented.

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.

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.

--tml