(dropping debian-kernel from CC as we're back to discussing the dpkg issue itself) 2012/7/14 Jonathan Nieder <[email protected]>: > clone 617299 -1 > retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR > submitter -1 ! > reassign -1 debian-kernel-handbook 1.0.13 > quit > > Martin-Éric Racine wrote: > >> The solution to bug #617299 is therefore to either define TMPDIR to >> some actual hard-disk with sufficient storage space via a commandline >> environment e.g. 'TMPDIR=/var/tmp make deb-pkg' whenever using >> commands that require an unusually large amount of /tmp space, or to >> completely disable the usage of a tmpfs for /tmp via initscripts >> defaults in /etc/defaults/rcS and /etc/defaults/tmpfs, as appropriate. > > Sort of. It's still a dpkg (wishlist?) bug. I would even think it > might be possible for dpkg-deb to write its output directly to the > expected target path or another file in the same directory.
Writing to the target path would indeed make sense. Just a wild guess, but dpkg probably uses /tmp because, by definition, it's guaranteed to be temporary and deleted upon reboot, whereas writing to target path might leave an increasing amount of cruft whenever a build repeatedly fails. Still, as the original reporter complained, blindly trying to figure out why a package repeatedly fails to build with "No space left" - even though it compiled succesfully - on a hard-disk with several GB of space, when it turns out that it's simply because dpkg uses as a scratchpad a /tmp that happens to be mounted as a small tmpfs, is a genuine problem. I am curious to hear what dpkg developers have to say about solving this particular one. Martin-Éric -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
