Re: dpkg minw32
On Fri, Jul 9, 2010 at 11:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Luke,
>
> Luke Kenneth Casson Leighton wrote:
>
>> 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.
>
> Check again? dpkg 1.1.4 from 1996 (oldest version I have handy) uses
> the ‘tar’ binary to build and extract packages. And modern dpkg has
> ./configure --with/--without-zlib and similar options to decide
> whether to use compression libaries or external compression programs.
really? _fantastic_. ha. thank you jonathan. harumph - could have
done knowing about that a year ago - should have asked back then,
shouldn't i? :)
ok. so that still leaves a sticky situation with using the tar
binary instead of libtar, and the fact that mingw32 doesn't have
fork(), and even _remotely_ considering attempting to use win32's
popen would result in a dog's dinner beyond all reasonable acceptable
coding standards. you only have to look at the hoops that python's
win32 implementation of "popen" to understand that (dup of HANDLEs,
system calls to associate with a filedescriptor, pass those across
process boundaries... nightmare).
was there any particular reason why dpkg farms out to tar, rather than
statically linking with libtar?
l.
Reply to: