I'm glad you made these comments; I'd been hoping someone with a view on
the Cygwin experience with RPM would pipe up.
Brian Dessent wrote:
> Keith Marshall wrote:
>> No. At the moment, your goal has to be to present a sufficiently
>> convincing argument, to persuade my development team that the
>> advantages of your proposed RPM solution so far outweigh the
>> capabilities of our existing NSIS infrastructure, that it's even worth
>> pursuing. I'm not yet hearing anything to convince me of that.
> I have to agree. I am one of the maintainers of Cygwin's setup.exe, and
> we have gone over and over this "why can't we just use RPM" debate a
> number of times in the past. I strongly recommend that you forget about
> it ASAP.
To point out what the advantages would be (I'm sure you know all these
arguments, and I'm not necessarily saying that these are enough to
justify all the work):
* You get command-line based management of your MinGW environment.
Linux developers porting to windows will appreciate this quite a bit
* You get a *database* of known files in the user's environment.
When a package stops working, you can use RPM to diagnose what has
been broken. For example if you (or someone else) accidentally
overwrites some system header file you can detect and fix that.
* Users can upgrade packages without having to worry that it will
* Users can uninstall a whole package or just the bits excluding the
configuration files (meaning they can can get back to exactly what
they had earlier)
* Porting software from linux via the .src.rpm becomes a much less
onerous task. At least it gives an easy starting point.
* RPM *does* provide the ability to relocate packages. With suitable
command line parameters they can be installed anywhere you like.
* RPM would be a stable foundation onto which various GUI
environments could be added; as far as I can see it doesn't
preclude a Cygwin style 'setup.exe' or NSIS tick-box style
installer for new users.
* Platform-independent 'noarch' RPMs could potentially be brought to
* All the dependency management stuff really is non-trivial; if we
can overcome the platform-specific issues then we get all that
complex but well-tested stuff for free.
* RPM includes a really good meta-data system that lets you inspect
what a package is *for*, who maintains it and what documentation
it contains, and how it can be configured. And all the tools are
there for producing browsable and searchable directories of the
packages, and downloading them from local mirrors, etc.
> Getting RPM usable for installing packages on Cygwin was
> deemed way too much work, so I can't even begin to imagine how long it
> would take with MinGW. You might as well be trying to teach a hippo to
> play the tuba; the requirements of packaging on POSIX systems and win32
> systems are radically different. Just off the top of my head, the
> potential issues are:
> - The RPM binary itself would have to be totally standalone, no
> depending on any runtimes. (This in of itself is a huge undertaking.)
> If it wasn't, then it would have problems upgrading itself, as in-use
> files work differently on Win32 than POSIX. Not to mention that you
> don't really want the installer itself to be a whole massive wad of
I don't see that it has to be standalone. As long as RPM and its
dependencies are in the database, it will be safe. This would probably
be a pre-initialised database that would be generated during the
installation of MSYS, I guess.
> - RPM installation uses scripting to accomplish things. This means you
> also need to provide a Bourne shell, and all the other related apps that
> might be used in the context of shell scripting (awk, sed, cat, ...) Or
> if you want, you use some other shell, possibly CMD.EXE but it of course
> is rather riduclous. Don't forget that if you want to support 9x/ME you
> can't even use any of the modern NT CMD.EXE niceties, you have to resort
> to the level of COMMAND.COM from MS DOS 2.x. (in other words, welcome
> to hell.)
You would definitely stay with the Bourne shell. There is the clear
advantage of using sh is that porting packages from Linux is as easy as
possible. The implication is that the 'core' MinGW system would
effectively be MSYS, with compilers etc being added via the RPM mechanism.
> - RPM was not designed with relocation in mind, as installation on POSIX
> is a fixed tree, whereas win32 users are used to being able to install
Maybe not, but it does have relocation capability. I have for example
used RPM to install old versions of Tcl/Tk on non-standard paths.
> And again, that's just off the top of my head. Seriously, I can't even
> believe anyone is actually thinking this is a good idea. Let's not
> forget that the simplicity argument of "take these packages and extract
> them to the same dir" is pretty hard to beat for installation. I happen
> to like that I can just grab these files and extract them whereever I
The problem is that you have no way of diagnosing problems down the
track, and no way of checking if you did it right. There is *so much* in
the area of dependency checking and tracking that is being quietly
ignored in the current approach. Granted, though, it works and it's simple.
> If you really want to improve the existing installer, just modify it to
> respect some very rudimentary dependencies, such as "if user picks gcc,
> make sure to select binutils, w32api, and mingw-runtime." That's all
> you really need, this is not the 4,000 packages of a linux distro.
The vision here would be that the vast world of linux software could be
ported to Windows if the foundations were there. At the moment MinGW is
just a set of development tools, but it doesn't have to only be that.
One thing I'm not up to date on is what the new vista windows provides
in place of 'add/remove programs'. If there were a system of dependency
checking provided there, then this would clearly be an alternative to
the whole RPM idea.