dpkg minw32
dear debian-pkg,
last year i began cross-compiling packages for win32 using mingw32
(installed under wine and also using mingw32-cross). i spent one week
fighting with libicu38 and 90 other dependencies just to get one
application compiled (webkit). i hunted down a dozen different
obscure bits of libraries and functions, patching things like libbz2
and other libraries that were missing flock and so on.
i don't know if you've ever thought about the implications of running
mingw32 under wine, but fork() on win32 doesn't really exist: the only
person who successfully implemented fork() under win32 was jeremy
allison, for cygwin, by - believe it or not - monkey-patching windows
system memory in undocumented system data structures. and, if you
don't / can't do that, you're forced to use exec(), and that means
_complete_ restart from scratch under bash for example. the use of
exec() means that instantly you get a security system call/check
overhead... but it's much worse than that.
whilst bash shell scripts on a linux system you can shell/exec() one
thousand new shell instances per second, on mingw32 native under
windows that comes down to one PER SECOND OR WORSE, and when running
the same mingw32-compiled bash under wine, it's truly truly madness.
you should see the strace logs: total reload of x11 libraries,
printing subsystem, termcap - reams and reams of unnecessary system
calls, _just_ to start a child bash shell.
by the time you are using ./configure or running autoconf, it can be
up to fifteen to thirty seconds to do a single line of autoconf
output.
i mention this as background because yes it was insane.
against this background, anyone actually making the effort... well...
the effort is completely wasted, because of the lack of formal
packaging on win32, to track dependencies. that _really_ hit home.
so, being a debianite, i looked up "dpkg win32" on google and found a
failed project. so, i tried cross-compiling dpkg myself. i found
that it, too, wasn't going to work, and the reason was that yes,
again: fork and popen are used, to communicate with tar, bzip2, gzip
and so on.
this is in direct contrast to dpkg of some years ago, where it used to
be (statically?) compiled with libtar, libz and libbz2.
so my question is this: why was the decision made to turn dpkg into a
pipe-based architecture, and can that decision be reversed, with a
view to removing any system calls which do not exist under the mingw32
architecture?
many thanks,
l.
Reply to: