On Jan 10, 2010, at 7:06 AM, Tor Lillqvist wrote:
> 
> 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.
> 

Sure patches for mingw would be acceptable @rpm5.org. BUt I can't
promise to "support" Windows, I'm a UNIX programmer and RPM developer,
and windows is just too different.

But I have no problem with dealing with patches under #ifdef's @rpm5.org.
I'll check-in patches for most anything that looks useful under
a private #ifdef.

> 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.
> 

Note that chroot(2) is increasingly useless (imho, from a design POV) on UNIX
as well. There's no reason a priori why chroot(2) *MUST* be used except for scriptlets,
where chroot(2) is an effective way to lock a scriptlet into a subtree.

All other usage cases (afaik) can be dealt with in RPM by prefixing
the chroot to the file path. That change will be painful, but isn't technically
hard.

> 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.
> 

Send along some patches and I'll try to integrate.

Note: Expect rpmtsRun() to be largely re-arranged into smaller
routines over the next few months. I'm just getting through an rpmdb
"RPM ACID" overhaul and there will be ripple effect as I rewrite/refactor lib/*.c
routines. Getting there, just haven't started yet. Vetting/adding Windows/mingw patches
at the same time won't bother me a bit.

hth

73 de Jeff