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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
