From: Charles W. <cwi...@us...> - 2009-04-19 14:07:57
|
Luke Kenneth Casson Leighton wrote: >> I know. We *really* need a flexible automated installer. Sigh. > > whatever you do don't reinvent one. > > please also don't pick rpm, it was always crap. that leaves portage > and dpkg as the sensible alternatives. There's also the cygwin setup program, and the MikTeX setup program. Both have their flaws, but a strength shared by both is that they are already adapted to operate on win32. So the changes required to work with/for mingw and msys are cosmetic. (Well, the tarball-name <--> metadata translation will need to be completely replaced by our package.l stuff. But that would be true of any system you adapt, because our package naming system has unique features not supported by any other platform/packaging system I know about. > portage is _very_ > source-code-orientated, forcing the installation of header files as > well as binaries. Yes. This is also both a strength and a failing of the MinGWPorts system. If we want to standardize on a source-based distribution system, we already have THAT in place. No need to change. Our issue is distributing pre-compiled binaries that comprise the core MinGW distribution, and to a lesser extent those that comprise the MSys environment. > debian policy (and therefore its developer toolset) > subdivides everything into two groups: the apps/libraries themselves, > and the source/headers/libraries (known as build dependencies) > required solely and exclusively by developers to _build_ the > app/libraries. > just like the mingw distribution does [separates developer files from > source from binaries] True, but so does EVERY system out there except the source-based ones like portage. > prerequisites and procedures are taken care of with dependencies, > pre_install and post_install scripts. great care has been taken to > avoid circular dependencies. This is mainly a function of the meta data in the debian/ area of each individual package. It has little to do with dpkg itself. > the use of a package manager would also help people avoid dll hell (as > long as they don't interfere with the installed / managed packages). The problem is that dpkg -- as you pointed out earlier -- "is very unix-centric. [It requires] flock, fork, pipe, waitpi, the usual." Also, because it requires *scripts* for post-installation activities it cannot be used to install only MinGW. You MUST install also MSYS, so that the postinstalls can be run. Furthermore, as a unixy application, it can really only work as an msys port without major surgery. Major surgery of this kind is really bad, because we obviously don't have the manpower. ALSO, as an msys app, then whenever it is running the msys DLL will be in use -- therefore, dpkg can't be used to update or install msys-core itself. > overall, dpkg is a good match. I don't think so. I think it is a 800lb hammer for a 3oz staple, and requires building a blacksmith shop and smelting the iron before we can forge that hammer, so that we can pound in the staple. -- Chuck |