Your message dated Wed, 7 Aug 2024 10:42:25 +0200
with message-id <[email protected]>
and subject line Re: Bug#977862: support systems without lchown, perhaps with
Gnulib
has caused the Debian Bug report #977862,
regarding support systems without lchown, perhaps with Gnulib
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
977862: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977862
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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])])
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.
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.
-- Package-specific info:
System tainted due to merged-usr-via-symlinks.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2022-10-12 at 22:24:21 +0200, Guillem Jover wrote:
> Control: tag -1 moreinfo
>
> 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.
Ok, closing this now, but see above.
Thanks,
Guillem
--- End Message ---
