On Mon, Mar 19, 2012 at 10:41 PM, Jonathan Nieder <[email protected]> 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAPweEDxcYWUomxHRKWrpxxQuFMqxtC=v50qctxwhdu4fu_f...@mail.gmail.com
