Re: libdpkg: m_fork and friends
On Mon, Mar 19, 2012 at 10:41 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> lkcl luke wrote:
>
>> performance is never a major issue here :) but
>> i believe, last time i looked, all the dependencies had been sorted
>> out (with one exception) by the mingw, msys and git-win32 teams. i
>> had to track down an implementation of flock but that was about it.
>
> Some examples from "Git for Windows" experience: Windows does not
> allow removing a file or directory that is open, nor modifying a DSO
> that is in use.
>
> Now compare this to dpkg's requirements, which include the ability to
> upgrade packages while they are currently in use (think: libc).
>
> Can you reconcile these?
*thinks*... i can think of a workaround. if all applications which
are required to perform an upgrade (dpkg itself, tar etc.) are either
entirely separate (chrooted copy) or are statically compiled (bit
messy) then all applications can be killed prior to an upgrade.
aside from that: my goals - uses for dpkg - are slightly different
from those of the debian-win32 group. the main one is for the
packaging tools, for use as a cross-compiling development environment,
where there may be windows users who should not be excluded from being
able to cross-compile packages just because the target is
debian-based. under such circumstances, there would be no usage of
libc, no file locking issues, and no packages in use at the time of
their being upgraded.
l.
Reply to: