Hello, === Addressing the participants in this thread more generally, especially those who seconded my most recent patch: === Bill has raised several scenarios in which this new requirement could be interpreted as making a package RC-buggy, where that might be considered unreasonable. Building in wording to avoid each of the cases would make the whole patch a lot more complex, but it could be done. An alternative would be for us to weaken the main requirement of the patch from 'must' to 'should'. That way, this patch would not be in the business of making any packages RC-buggy. I don't think Bill thinks his cases are not bugs, just that they are not of RC severity. A third alternative is that we just keep the patch as it is now, and rely on maintainers to exercise their judgement about the corner cases that Bill describes. So in summary, we can 1) make the patch a lot more complex, in order to reduce to bugs of normal severity situations where a package build: (i) harmlessly ignores TMPDIR, or (ii) leaves files in TMPDIR which do not affect further builds; or 2) weaken the main requirement from 'must' to 'should'; or 3) not explicitly account for Bill's cases. Concerns about (1): Policy becomes a lot less useful if we complicate the wording to build in all sorts of exceptions, where good judgement on the part of package maintainers could handle those cases just fine. I am apprehensive about the idea of distinguishing between 'should' and 'must' within the explicatation of the details of two exceptions to a 'must' requirement. The gain seems so minimal for the loss of readability. Concerns about (2): it seems to me that this would not reflect the project's consensus that source package builds really should not be writing to places outside of TMPDIR and their own trees, aside from the final generated binary packages. So I am inclined towards (3) myself, but would very much like to hear other's opinions. === Addressing Bill's most recent message in particular: === On Sun 11 Nov 2018 at 04:04PM +0100, Bill Allombert wrote: >> > What about the severity of using /tmp even if TMPDIR is set ? >> > I do not think it is RC outside of the build process so it would >> > be inconvenient. >> >> The current wording makes that RC-buggy, indeed. >> >> What exactly do you mean by "not RC outside of the build process"? > > Debian policy does not mandate that packages support TMPDIR, > so it is valid to package a program that does not support TMPDIR and > always use /tmp instead. > > However if some other package use this program in its own build process, > then this other package is RC buggy under this new rule. This can be > inconvenient. Okay, thanks, I see what you mean now. > Do we have some data about how many packages fails to honor TMPDIR ? Not to my own knowledge. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature