Hi! On Mon, 2020-12-21 at 23:02:29 -0500, John Scott wrote: > Source: dpkg > Severity: wishlist > Tags: upstream
> Just to see what trickery I could get away with, I tried cross building dpkg > with MinGW. It fails due to lchown being missing, but it seems like this is > one of the only functions that dpkg dies on not finding: > AC_CHECK_FUNCS([memcpy lchown], > [], [AC_MSG_ERROR([missing required function])]) Ah nice. > I notice there's precedent for incorporating something into libcompat, > which actually looks a lot like Gnulib. From the outside it looks like > reinventing the wheel and I'm curious about that, but either way Gnulib > has a module that may help portability on other platforms. The libcompat (known before that as getopt/, and before that as optlib/) was initiated before my time. Personally I find gnulib too fat, I'm not fond of its usage method pattern (I think ideally it would be shipped as a shared/static library, instead of requiring embedding), and I've found usage of GPLv3 on some of its code problematic (given that dpkg has had GPLv2-only C code in the past. External dependencies are also problematic with dpkg, as it increases the bootstrapping size. And finally not using something like gnulib, also makes it more obvious what is desired to be supported and what behavior can be relied on or guaranteed on the supported systems. > It appears it just dies with ENOSYS on MinGW, at least for now, but I'll > take it :) > https://www.gnu.org/software/gnulib/manual/html_node/lchown.html > > If you wish to avoid embedded code copies, the Gnulib Debian package has it. > Otherwise a similar libcompat function that dies might still be fun to try, > and if it bears serious consequences perhaps a flag could be required to > enable. 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. :) Thanks, Guillem
