Control: reassign -1 dpkg-dev,debhelper Hi!
On Thu, 2019-10-10 at 14:58:11 +0100, Simon McVittie wrote: > Package: dpkg,debhelper > Severity: wishlist > I'm reporting this feature request against both dpkg and debhelper because > I don't yet know whether it's feasible to implement in debhelper, and > if it's feasible in both places, I don't know which location is where > it *should* be implemented. > Problem statement > ----------------- > > Debian Policy ยง4.9 requires the build process of a package (defined in > terms of the "required targets" in d/rules) to limit its write accesses > to one of a few allowed locations: > > - the unpacked source package being built > - /tmp > - /var/tmp > - $TMPDIR > - (https://bugs.debian.org/942051 points out that some other locations > like /dev/shm should also be allowed) (BTW, I think some of the other locations presented are due to a very strict interpretation of the wording, which do not follow the spirit of the requirement.) > Pasting similar setup code into increasingly many packages as their > Policy violations are discovered does not seem like an ideal solution > when the problem could be solved centrally instead: instead of fighting > against these packages, we could relax the requirement to allow use of > $HOME, while ensuring that $HOME is set to a clean per-build directory. Indeed. > Proposed solution > ----------------- > > Either dpkg-buildpackage should: > > - create a fake home directory, perhaps debian/.temp-home/home, and set > $HOME to point to it > - create a fake XDG_RUNTIME_DIR, perhaps debian/.temp-home/run, and set > $XDG_RUNTIME_DIR to point to it > - delete those directories during cleaning > - either unset the other XDG_* so that their hard-coded defaults are used, > or set them to known-good values, using the fake $HOME where applicable: > - XDG_CACHE_HOME: $HOME/.cache or unset > - XDG_CONFIG_HOME: $HOME/.config or unset > - XDG_CONFIG_DIRS: /etc/xdg or unset > - XDG_DATA_HOME: $HOME/.local/share or unset > - XDG_DATA_DIRS: /usr/local/share:/usr/share or /usr/share or unset Right, there are a few problems with this though. The first is the directory use, which might stomp over local packaging stuff. Then the cleanup, which needs to be delegated to debian/rules, although I've discussed with Niels to add a new dpkg-buildclean command or similar. I've got a pending proposal to solve problems such as this, but I've found no motivation the last several months to bring this up on debian-devel. I'll try to find some, and sent it, but meh. The draft is at: <https://www.hadrons.org/~guillem/tmp/draft.build-path> The other main problem is yet again with dpkg-buildpackage not being (still) the main and only canonical interface to build packages, so debian/rules must keep working as before, per policy w/o externally defined variables. :/ > or dh should do all of those in dh(1), and optionally in other dh_* > commands for the benefit of packages that do not use dh. As it is now, while I think that would be just suboptimal, and would not cover non-dh debhelper packaging, that might be better than nothing. :/ > Limitations of proposed solution > -------------------------------- > > If a package is built in an unclean environment that includes > variables other than those that are reset explicitly (for example with > PYTHONPATH=$HOME/.local/lib/python3), it will continue to read and/or > write the home directory. (Solved by using debuild or sbuild.) Cleansing the environment is something that dpkg-buildpackage should be doing too, but given the current interface requirements (of debian/rules being the official entry point), doing this by default in dpkg-buildpackage would induce breakage when maintainers start assuming the new environment. > If this is solved in dpkg-buildpackage, and a package is built by invoking > debian/rules directly, it might bypass this solution. (Solved by using > dpkg-buildpackage, or anything that wraps it, like debuild or sbuild.) Yeah, which might mean unexpected/broken behavior. > If the user specifically *wants* to write outside the build directory, > for example because they are using ccache with cached files in the > default ~/.ccache, it will no longer be sufficient to run "debuild > -ePATH=/usr/lib/ccache:$PATH"; the user will now also have to pass in > an explicit CCACHE_DIR. (Mitigation: they already need to do this for > increasingly many packages that have solved this problem locally, like > glib2.0.) Right, if the default got to switch to a cleansed environment, I don't see a problem with people having to adapt to that. > Where do the dpkg and debhelper maintainers think this ought to be solved? IMO this should be done centrally in dpkg-buildpackage, but only if that's the only supported entry point for building packages. As long as the entry point is still debian/rules, unfortunately I think we need to make do with possibly inferior solutions, which less coverage or more repetition. :( Thanks, Guillem
