Ian Jackson wrote:
Program call is also a natural facility on (virtually) every OS... the semantics vary from platform to platform. On win32, the program is invoked directly, rather than using a 2-stage fork-execute.Raphael Hertzog writes ("Re: Why does dpkg invoke find instead of doing own searches?"):On Wed, 12 Dec 2007, Phil Lello wrote:One option is to have the win32 version of archivefiles do the find itself. It would be trivial to do the POSIX version of the code at the same time, if this is useful.I guess nobody will object to this.I object. We should not add code to dpkg unecessarily. Program call is a natural facility on Unix, which dpkg makes extensive use of.
Implementing the find functionality natively adds to robustness, since it removes run-time dependencies. The only other times (that I've seen so far, at least) that dpkg invokes external programs is when it calls other programs from the same package.
Can you give an example of 'other design compromises'? I haven't found the need to make any, and I'm working on the port.Note that Phil's request is a slippery slope: we'll be asked to make other design compromises too.
How is it wrongheaded? What costs to (y)our own use do you think are involved?I'm afraid I'm going to take a hard line and say that attempts to port dpkg to win32 are wrongheaded and that we shouldn't burden our code with them. Or to put it another way, we should not accept even small costs to our own use of dpkg in order to save effort for those trying to use dpkg on Windows. Ian
I may have mis-understood, but it sounds like you're objecting to a win32 port for philosophical reasons. Are there any _technical_ justifications for this?
Phil