Control: tag -1 moreinfo Hi!
On Mon, 2021-08-23 at 22:51:25 +0200, Guillem Jover wrote: > So, while I'm truly interested in improving portability for dpkg, I'm > not sure (as in, I've not kept up with times) whether MinGW might be a > valid target at all? Also AFAIR there's still the problem with its > GNU system name not being ready to be merged in dpkg. >· > dpkg does still make use of fork+exec constructs, which AFAIR were > problematic on Windows-based systems, and while I'm slowly getting rid > of them, this is still the case. >· > Then there's the dpkg requirements on filesystems > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_the_filesystem_requirements_by_dpkg.3F>. >· >· > If lchown() is really the only thing stopping dpkg to be buildable and > runnable there, I'm happy to consider options here. I think Windows > gained better symlink support "recently", wouldn't adding lchown() > support to MinGW be a better option here? But otherwise if there's a > possibility to add a non-stub version of the function I'd be happy to > take a patch for it. :) So given the above, if there's no further input, I think I'll be closing this in a bit, as this could always be reconsidered once the arch name situation is solved or a better alternative exists. Thanks, Guillem
