libdpkg: m_fork and friends

[Phil Lello]

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.

Thanks,

Phil

[Dalibor Topic]

Post by Phil Lello
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.

You could try using glib for that.
http://library.gnome.org/devel/glib/2.14/glib-Spawning-Processes.html

cheers,
dalibor topic

[Phil Lello]

Post by Dalibor Topic

Post by Phil Lello
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.

You could try using glib for that.
http://library.gnome.org/devel/glib/2.14/glib-Spawning-Processes.html

It might be worth using glib to spawn child processes, to reduce
os-specific code in dpkg, however this does mean introducing glib as a
dependency, which may or may not be desirable.

I'll move this conversation over to the dpkg list, as this seems more of
a general dpkg design issue than a Win32 specific one.

Phil

[David Moreno Garza]

Post by Phil Lello
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
- 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?

--
David Moreno Garza <***@espiral.org.mx> | http://www.damog.net/
Por besar tanto culo ya te apesta la boca.

[Phil Lello]

Post by David Moreno Garza

Post by Phil Lello
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
- 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

[David Moreno Garza]

Post by Phil Lello
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.

Just out of curiosity, has there been any progress?

Cheers,

[Phil Lello]

Unfortuantely not yet; my development box died with filesystem
corruption (either the hard-disk or controller, so I've replaced both),
and I'm still recovering data.

Hopefully I'll get back on this in the next few days, and be more strict
about backups

Phil

Post by David Moreno Garza

Post by Phil Lello
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.

Just out of curiosity, has there been any progress?
Cheers,
--
We're gonna rock this motherfucker like three the hard way!