Re: Why does dpkg invoke find instead of doing own searches?
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
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
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
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?