Re: libdpkg: m_fork and friends

David Moreno Garza wrote:
> On Mon, 2007-12-10 at 02:39 +0000, Phil Lello wrote:
>   
>> Hi all,
>>
>> I've started trying to port dpkg natively to Windows (as opposed to 
>> using Cygwin).
>>
>> One area that may cause problems is that Windows doesn't have fork 
>> functionality, so implementing m_fork() will be challenging.
>>
>>  From what I've seen so far, the only time m_fork gets used in the dpkg 
>> source is as part of the process of spawning a child to do some work, 
>> and writing Win32 child-spawning code should be pretty simple.
>>
>> This is all well and good as long as no other packages are using the 
>> m_fork (and possibly m_pipe/m_dup2) code. So my questions are:
>>
>>     - Are other packages supposed to use m_fork, m_pipe, etc?
>>     - If not, do we know of/care about packages that do use it?
>>     - If so, would breaking API compatability to allow a Win32 port be a 
>> problem.
>>
>> Please note that my last question is badly phrased... it would _only_ be 
>> the Win32 port that would have a changed API, specifically the functions 
>> that can't be (easily) implemented (m_fork, possibly m_pipe/m_dup2) 
>> would be #ifdef'd out.
>>     
>
> Are you hosting your project somewhere?
>   

Not yet, as I'm hoping that I can get this integrated into the main dpkg 
tree, rather than forking a separate project. Failing that, a win32 
branch off the dpkg svn repository would probably be the next-best solution.

I seem to be making good progress, and hope to have a patch for review 
within the next week, provided there isn't negative feedback to my 
questions about the libdpkg changes.

Phil