![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Email simplification through gross hacking
I'm in the process of converting my two Debian unstable boxes (call-with-current-continuation, an AMD64 laptop, and watertown, an IA32 desktop) into Ubuntu Breezy Badger boxes. The goal of this is to stop running Debian unstable, so that I can stop reading multiple high-traffic mailing lists that are at this point largely irrelevant to my life but I feel like I need to keep up on to know about the library breakage of the week.
In principle the conversion isn't that hard: just change /etc/apt/sources.list to point at Ubuntu and feed the new package list through Aptitude. In practice it's long and annoying because there are lots of package downgrades that Aptitude won't schedule on its own. There's a large class of problem of "file X moved from package A to package B, but there's no Conflicts: header" which results in APT getting stuck (can't install older A without installing older B first, but the ordering algorithm always picks A).
You really should expect every major subsystem to break if you're doing this. On call-cc, the libc6 upgrade removed /lib64 which is fine except that AMD64 binaries expect the system dynamic loader to be there, so suddenly nothing worked at all. Go SysRescueCD! The kernel upgrade took effort. X takes effort. Both of the last two are still broken on watertown.
The basic update process works out to: start aptitude. Mark a bunch of packages for downgrade. Start it. Notice which package specifically broke, figure out how to fix it, fix it in a different virtual console while aptitude shows the "press return to continue" prompt after running dpkg (before you get back to the full-screen view). Mark the same bunch of packages for downgrade, again (aptitude knows that no sensible person would really want to downgrade that many things). Lather. Rinse. Repeat.
I was happy on call-cc when both the ATI video driver (fglrx) and ndiswrapper showed up in the normal kernel packages. On watertown apparently openafs isn't. This is sad, but rebuilding just one package from source is still better than two or three.
In principle the conversion isn't that hard: just change /etc/apt/sources.list to point at Ubuntu and feed the new package list through Aptitude. In practice it's long and annoying because there are lots of package downgrades that Aptitude won't schedule on its own. There's a large class of problem of "file X moved from package A to package B, but there's no Conflicts: header" which results in APT getting stuck (can't install older A without installing older B first, but the ordering algorithm always picks A).
You really should expect every major subsystem to break if you're doing this. On call-cc, the libc6 upgrade removed /lib64 which is fine except that AMD64 binaries expect the system dynamic loader to be there, so suddenly nothing worked at all. Go SysRescueCD! The kernel upgrade took effort. X takes effort. Both of the last two are still broken on watertown.
The basic update process works out to: start aptitude. Mark a bunch of packages for downgrade. Start it. Notice which package specifically broke, figure out how to fix it, fix it in a different virtual console while aptitude shows the "press return to continue" prompt after running dpkg (before you get back to the full-screen view). Mark the same bunch of packages for downgrade, again (aptitude knows that no sensible person would really want to downgrade that many things). Lather. Rinse. Repeat.
I was happy on call-cc when both the ATI video driver (fglrx) and ndiswrapper showed up in the normal kernel packages. On watertown apparently openafs isn't. This is sad, but rebuilding just one package from source is still better than two or three.