A little dpkg wierdness after upgrade to testing

[Neal Lippman <nl@lippman.org>]

I noted a little weirdness with apt-get and dpkg after my dist-upgrade
from woody->testing tonight.

My practice is to run in my usual user-level account (nl) and use sudo
for all root-like operations. When I install, for install, I use 'sudo
apt-get install <frotz>' and so on. That has always worked just fine,
even when my current directory is /home/nl.

Of note, however, /home/nl is just a symlink to /nfs/nl, and /nfs is
(surprise) and nfs mounted share from my fileserver. The relevance of
this is that when running as root on my workstation, I cannot
create/access files in my usual home directory (/home/nl) because that
maps to the nfs share which as root_squash for security reasons.

Now, to the point. After the dist-upgrade to testing, when I do sudo
apt-get install <frotz>, it fails because it is trying to create a file
called .dpkg (or something similar) which it cannot do, because my
current working dir is /home/nl.

Of course, it's easy to fix this by just cd'ing to /tmp which is mounted
on a local partition. 

However, I bring this up because this did NOT ever happen under woody.
This makes me think something has changed in apt or (more likely) dpkg -
and apparently dpkg is trying to create a file in teh home dir of my
personal account even though, via sudo, it should be finding the home
dir for root.

I don't know if this is a bug, feature, or "don't care" - but I thought
it was worth asking about.

nl