On Sat, 23 Aug 2003, Joey Hess wrote: > It's interesting to examine what information about maintainers' build > environments slips into binary packages, and consider the possible > consequences and what, if anything, we can do about it. > > Here's an annotated and edited version of the output of the command > strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \ > egrep '/home/.*/' | sort | uniq > If you're only interested in checking your own packages, I suggest > instead, > for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done > > /sbin/start-stop-daemon: > /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c > # Given the __assert_fail in the symbol table, this is probably > # displayed as part of an assertian. One of the more common cases. > # > # Of course this leaves the user wondering why the program is > # complaining about this "adam" person and his nonexistent home > # directory. Hmm, raid0? > # > # Note that assert only puts the full path to a file in if you give that > # full path to gcc. A minor modification to dpkg's Makefiles would > # convert this into just "utils/start-stop-daemon.c" and save us all a > # few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc.
I've thought about doing this for dpkg's build system, before, because of the long path that is encoded. I'll probably be part of dpkg 2.0.