Hello Eugene, > On Sat, Sep 25, 2021 at 09:29:42PM +0100, Samuel Henrique wrote: > > > for lchown() is definitely a new feature, so the right way, IMHO, > > > is to correct dependences for rsync package: "libc6 (>= 2.31)". > > > > I don't think it's as simple as that, I understand your issue now, but > > I wouldn't just bump the dependency requirement without understanding > > it better. > > As it stands now, the version requirement is automatically set by > > debhelper, based on the symbols rsync uses. > > Are you sure about version? I doubt. The list of libraries is built > by debhelper, I agree. But the *version* dependency, IMHO, can't be built > on the list of referenced symbols.
Yes, I'm not setting the required libc6 version anywhere, that's automatically done by dpkg. > To build version dependency automatically script should have access > to the whole history of all versions of libc6, with list of symbols > and markers when each symbol become usable. We have that, you can read about it here[0][1][2], if you're interested. > Note that presense of > symbol is not mean usability: for libc6-2.30 entry "lchown()" is > definitely present (ltrace confirms it), but attemptp to call it > return an error "not implemented", i.e. this version contains only > stub code (symbol is reserved for future use). Yes, that's why the version automatically picked doesn't solve this issue; the symbol was there before, it just changed behavior. The symbols are also provided by a human so there's always room for mistakes there, but that's not the case here. > I belive the version dependency have to be filled manually. Moreover, > with manual assignment buggy versions of library can be excluded, > which is very unlikely to be done automatically. We can also do it manually when needed, and that's my plan B[3]. > > The bug we are facing comes from libc6, as we can see in the upstream > > bug report, and rsync is trying to workaround that issue (the patch I > > introduced on 3.2.3-7). > > I did not look through the code, but probably it detects presence of > lchown() but don't cover the situation when this entry is not functional. Yes, I believe that could be what's happening with rsync's workaround. > > Having outdated packages is not a problem, but having only a subset of > > them is an indicator of something wrong. Rsync 3.2.3-7 migrated to > > testing after libc6 2.32, so this issue will not happen unless the > > person purposely holds libc back. I thought your system was running > > like that by accident. > > I'm not judging here, I just meant to explain that the trigger to the > > issue will not affect every Debian user. > > Yes, this issue may occure when libc6 vesion is outdated in normal > upgrade process. I would disagree on the definition of a normal upgrade process, one would never end up with a combination of incompatible rsync + libc, that can only happen if somebody installs a package that is not supported by Debian (not from the official repos) and that package holds libc back (thus running an unsupported version)[4]. This doesn't necessarily mean your bug report is not valid, this issue could mean I wouldn't be able to backport rsync, so I appreciate you reporting it. > OK, I expressed my thoughts, technical problem is clear, so > it's left for you and upstream to find the best and right solution. I did try to reproduce the issue on Jessie, with libc 2.28, but I was able to run "rsync -va /etc/ld.so.cache /tmp" with no issues. It might be possible that the issue you're seeing only affects libc between 2.28 and 2.31, if that's the case, it will be very tricky for me to reproduce since Debian only supports 2.28, 2.31 and 2.32. I want to try it again, but this time by trying to reproduce the issues I've seen in our CI system, let's see how it goes. If you have an affected system at hand, I would kindly ask you to try to implement upstream's workaround[5] and see if it makes your issue go away. Just a small correction, I see you mentioned lchown, but the issue is related to lchmod. I reckon you understand this, and it was just a typo (easy to mix both together). I'm only mentioning this to avoid confusion from someone else reading this. [0] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols [1] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols [2] https://wiki.debian.org/UsingSymbolsFiles [3] That is, if we confirm that this is a bug and upstream doesn't address it, though it's looking like upstream would be happy to fix it, removing the need for the version requirement. [4] It could also happen if a person does a partial upgrade between releases with official packages only, but then it's something we can't really say we support. [5] https://github.com/WayneD/rsync/issues/109#issuecomment-927481747 Thank you, -- Samuel Henrique <samueloph>
