Hi,
It's nearly time for Debian Stretch to be released. When that happens (and GitLab releases packages for it), we want to upgrade the system quickly afterwards.
In preparation, I'm working on trial runs for the base OS upgrade. As a consequence, performance may be degraded. To facilitate the upgrade (make it more quick), I reviewed all packages installed on the system with the purpose of removing unused ones.
I've removed quite a few packages indeed (from the current production system, that is): all packages related to the X11 (server) have been removed. So have most LaTeX and LuaTeX packages. The idea behind this step is that the access provided by Common-Lisp.net is merely provided to support uploading and maintaining the static html pages -- my assumption is that that has little relationship to being able to start a desktop environment or graphics environment.
If you miss packages that you depend on, don't hesitate to speak up. Please explain what you need them for and I'll make them available again.
While going over the upgrade process, I'm doing the so-many-th round of configuration cleanup: due to the fact that the host has been managed by multiple people at various times in the past, each with their own approaches to managing the configuration, the configuration can be much more standardized. On each round of maintenance, that's exactly what I've been doing. Configuration is more-and-more getting in line with "how Debian intends it". Let me use this e-mail as an opportunity to ask current and future (co)maintainers to stick to it; it's often a learning curve, but saves a lot of effort on upgrades later on.
There will be a pre-notification and some (planned) downtime for the system when the final cut-over arrives.
For those interested in how the migration strategy and dress rehearsals work, I'm going over these steps (wash, rinse, repeat -- in other words: over and over until it works):
1. Create LVM writeable snapshots of the VM's volumes 2. Create a new VM on top of these snapshots 3. Start up the new VM with different IP and hostname settings (patched Apache config too) 4. Change the (git-versioned) /etc directory to the new target distribution version branch 5. Run dist-upgrade (and a number of additional steps) 6. Fix the configuration issues found in the resulting installation and commit (to another server) 7. Ditch the copy-VM and go back to (1)
This procedure, although it's taking quite a bit of time to run the dist-upgrade, is turning out pretty effective in producing a reproducible upgrade procedure which can be repeated consistently once the production server needs to be upgraded.