[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#994275: Reverting breaking changes in debianutils

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

> 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.


> Thanks,
>     smcv

Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature

Reply to: