Adam Borowski wrote: >On Wed, Feb 12, 2020 at 06:10:53PM +0000, Steve McIntyre wrote: >> >> /me ponders - this could be a fun task for a GSoC/outreachy student to >> hack on, maybe? > >Prior art: > >* my unfinished https://github.com/kilobyte/crossgrade -- does a lot of > error checking and continue-after-problem, but currently stops after > crossgrading the essential set > >* stuff linked from https://wiki.debian.org/CrossGrading
Ah, cool! >Problems: > >* crossgrades fail _badly_ in a hard to recover way if packages for the > two architectures come in different versions (including binNMUs). This > hurts especially if -ports archs are involved. Yup. Probably best done on top of a stable release, by default, to avoid the worst of this, >* arch-specific or local packages are not as bad but 1. crossgrade must > know what's safe to remove, 2. what should be left unchanged (and their > recursive deps unremoved), 3. there may be non-multiarchable packages > within 1. or 2.'s dependency chain Yup. So I think it would be good to have a tool which can work through the existing state of a system up-front and analyse what's likely to work or not. >* systemd can't handle being crossgraded (I'm a systemd hater, but same was > noticed by eg. anarcat and Simon Richter). On a minimal system it may > survive but usually it starts killing daemons (including X), unmounting > stuff, choking and forcing an unclean reboot, etc. This could be worked > around by: > ⢠switching to sysvinit > ⢠booting from a different media then chrooting to crossgrade (not for > ordinary users unless it's eg. scripted from d-i) > ⢠having a package bring a grub entry that boots with > init=/usr/sbin/crossgrade to do the thing? ACK. Booting in a *simple* state is likely to be key. -- Steve McIntyre, Cambridge, UK. st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
