Hi Simon On 2021-10-11 01:01:45 +0100, Simon McVittie wrote: > On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote: > > The release team has so far protected users of testing from the > > problem by blocking testing migration, but this is not a long-term > > solution. > > Adrian asked in #994275 for changes in several topics to be reverted: > > - which(1) deprecation > - deprecation warnings on stderr > - management via alternatives > - possible future removal > - tempfile(1) removal > - installkernel(8) moving from /sbin to /usr/sbin > - run-parts(8) moving from /bin to /usr/bin > > Which of those topics were your reason for adding a "block debianutils" > hint? Are there any of those topics whose resolution you would consider > to be a prerequisite for letting debianutils migrate to testing again? I don't care about which(1). My reason for blocking debianutils was the tempfile(1) removal, but I suppose now I would add the last two points to the list as well - but usrmerge is the topic of another CTTE bug anyway. > The hint references #992399, which is related to tempfile(1), but > #992399 has been closed (via a merge with #992396, which was resolved by > debianutils adding a versioned Breaks on x11-common versions that needed > tempfile). Do the release team consider #992399 to have been adequately > resolved, or do you consider debianutils to still have a RC bug? I don't consider #992399 to be fixed. I specifically asked for a coordinated transition for the tempfile removal in that bug. So far I see no indication that this transition is coordinated in any way. As far as I can tell, the current strategy is to hope that users of unstable install a large enough set of packages to discover all the remaining uses of tempfile in maintainer scripts. See #993621, #994877, #996099 (which I just filed after a grep for tempfile in /var/lib/dpkg/info) for the latest examples. I think it would have been easy enough to follow a more systematic approach by processing the whole archive with piuparts to detect all the remaining cases. Additionally, Debian Policy 10.4 and the lintian tag possibly-insecure-handling-of-tmp-files-in-maintainer-script still recommend "tempfile or mktemp". Beyond tempfile(1) in maintainer scripts, random uses of tempfile are still being reported. See #995583 for the latest example. But also for this case, I see no coordination. > If debianutils reinstated tempfile(1) in bookworm, and removed it in > testing/unstable after the release of bookworm, would the release team > consider that to be an adequate transitional period? Helmut has shown how to remove interfaces from the essential set with e2fsprogs. But I think e2fsprogs was in a much better place when this was done: the interesting interfaces were moved to util-linux and for the remaining users of e2fsprogs it was easy enough to add dependencies. tempfile(1) however is used in maintainer scripts with the potential for upgrade failures. At least for that case I would expect that all the users are fixed in release $x and then tempfile could be removed in $x + 1. For all the other uses of tempfile, I'm currently lacking an overview. Cheers > > Thanks, > smcv -- Sebastian Ramacher
Attachment:
signature.asc
Description: PGP signature