darkness

• Not having less after a (minimal) install was killing me.
• It would be nice if apt-get install would keep a log of what packages I was installing, so I know which ones I’ll want for my next Debian installation (which might be… today).
• Debian seems to generally have more granular packages than RH/FC. For example, NTP is broken down into ntp, ntp-server, ntp-simple for a configuration, ntp-doc, ntpdate, and I think a few more. I consider this granularity to be generally a good thing.
  • One exception I’ve found: OpenSSH seems to be entirely in ssh (OK, OK, maybe there’s an ssh-askpass or something too). RH/FC breaks this up into openssh-server and openssh-client.
  • In fact, I found the package name ssh a little scarier than openssh; was I installing some ancient SSH 1.x? Of course, the description line said “openssh” so I’d know it was safe. (One could now talk about how RH/FC calls Apache httpd, for example.)
• When looking for the name for NTP (xntpd? ntpd? ntp? NTP?) I went looking for the URL to the upstream on packages.debian.org’s information about ntp. I can’t find an upstream URL anywhere. RPM spec files often have this URL in the URL: field. Where is it for debs? This is useful information.
• I installed ntp-simple and it started ntpd. Then realized I needed ntpdate. I installed ntpdate, which killed ntpd, ran ntpdate, and then… didn’t restart ntpd. Oops?
• Little things: apt-get install doesn’t ask for confirmation if it only needs to install what you specified on the command line (i.e., no dependencies needed). yum install always asks for confirmation (which is probably why I often use yum -y install). I didn’t realize how annoying that confirmation prompt in yum was until I stopped having it so often with APT.
• Argh dir_index isn’t turned on for ext3 filesystems by default. Did I miss where you can enable that from the installer? dir_index makes things so much faster with ext3. Now I have to enable the option on all my filesystems, then boot in such a way that I can e2fsck -fD them. Pain in the ass.
  • Slight offset to this pain in the ass: set SULOGIN=yes in /etc/default/rcS, then enter you root password and e2fsck from there. RH/FC doesn’t have this “always run sulogin” sort of feature, AFAIK, and now I wish it did.
  • Before anyone says “Sarge is old” as a defense to why it doesn’t use directory hashing: Sarge uses 2.6.8. RHEL 4 uses 2.6.9 (well, you know, RH patched 2.6.9) and AFAIK it turns on dir_index by default. Assuming I don’t hit some catastrophic filesystem corruption issue, I don’t see why Sarge doesn’t turn it on.
• APT pinning is still really cool. I just used it to upgrade Sarge’s kernel to the one from Sid. Surprisingly to me, the system was still bootable and everything.
  • One problem I had was that Perl started bitching about missing locales, since the locales package was upgraded along with the kernel. I have no idea if this really screwed anything up, but I ran dpkg-reconfigure locales again, checked to make sure I had en_US ISO-8859-1 and en_US.UTF-8 selected. When I ran dpkg-reconfigure by hand it seemed like there were some actions taken at the end to actually build the locales that weren’t taken at install time. Maybe it would be wise to upgrade locales by hand first (along with any dependencies; libc perhaps?), then upgrade the kernel.
  • In the process of removing the old kernel-image package it went into config-files status. I gather this means “we’ve removed all of this package except for configuration files you might want to keep around.” Fine, great. So I ran dpkg --purge kernel-image-whateverversion. Now, according to dpkg -l that kernel-image package is in the “not installed” state, with “purge” being the desired state. Poking around more I see I can spot some “unknown” desired state, “not installed” state packages with stuff like dpkg -l '*kernel*'. But it’s not showing me all avilable packages, as judged by doing apt-cache pkgnames | grep ^kernel. Maybe dpkg -l only knows about packages you’ve had installed at one time or another? I made some of these “weird” dpkg -l entries disappear with dpkg -\\-clear-avail or dpkg --forget-old-unavail. All in all, I find this confusing. I hope there’s a good reason for dpkg to know about uninstalled packages and then expose this information so easily.
• On a side note, while looking for information about APT, I found that the “Debian Reference” has some good suggestions on running an unstable desktop on an otherwise stable machine using chroot. I find that to be a pretty cool idea.
• I also gather that Aptitude, which I previously thought to be a GUI program only, has both a curses and a command line interface. Furthermore, if you use it to install a package, and then to remove that same package, the removal will also attempt to remove any unneeded dependencies of the target package. In other words: fewer orphaned packages hanging around. I gather there are some other tools that attempt to do stuff like this, deborphan being one. Anyway, this is a cool feature of Aptitude.
  • Er, but wait: why does it seem like Aptitude’s command line (i.e., aptitude install) doesn’t tell me about recommended and suggested packages, like apt-get install does? I guess I’ll keep using apt-get…

Since APT won’t keep track of it, I will! Packages I installed:

ssh less screen ntp-simple ntpdate rsync sysv-rc-conf vim iproute lsof sudo lynx elinks cvs strace ltrace lftp nmap iptraf ltrace units binutils smbclient dnsutils tcpdump

May want to add apt-file to this list.