Package: apt, Version: 0.3.16 When upgrading a 2.1r4 system with ca. 600 packages to 2.2 (2000-02-23 snapshot), "apt-get upgrade" failed dozens of times during post-inst. To clear "dpkg -C" (and "apt-get upgrade") I had to reload ca. 150 packages manually with dpkg.
Immediately prior to apt-get bombing it almost always had a line something like Dpkg::... mount /usr -oro,umount... busy... failed (I didn't write down the exact message, and now I can't recreate the message since my system is fully upgraded after several hours of tedious work.) To say I was shocked by this message is an understatement - AFAIK I was never asked for permission to remount /usr read-only during the installation of apt or dpkg. This is clearly a policy decision which must be left to the system adminstrator -- and which is a *huge* headache when dpkg makes assumptions about what the user wants. To the point, "apt-get install" usually succeeded. But "apt-get install" left /usr "read-only", so I was forced to remount /usr read-write every time. It was literally easier for me to run "apt-get upgrade" until it bombed, then run dpkg manually (which didn't remount /usr), than to try to load hundred of packages individually and remount /usr because some idiot decided to force a policy decision on me. N.B., I know why /usr should be mounted read-only... and I usually run with my system set up that way. But it should be left to the user to make that change - the user knows if they're installing one package, or one hundred, and anyone running dpkg should know local policy regarding read-only partitions. I DO NOT APPRECIATE WASTING HOURS OF TIME BECAUSE apt/dpkg CAN'T EVEN LIVE WITH THE POLICY DECISION IT SEIZED FROM ME. Also, modifying apt or dpkg to remount /usr as read-write is *not* a valid solution to the "apt-get install" problem, since it potentially violates site policy even worse than remounting /usr as read-only. As mentioned above, this is the snapshot from 2000-01-23, and the 2.2.14 kernel.
