On Sat, Dec 17, 2016 at 09:45:01AM +0100, Wouter Verhelst wrote: > On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote: > > On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > > > > > One way in which the need to keep armel around would be reduced is if we > > > could somehow upgrade from armel machines to armhf ones, without > > > requiring a reinstall. > > > > There is a script for that here: > > > > https://wiki.debian.org/CrossGrading
Considering my inept attempts to make such a script, this one is way too fragile to actually use. In my experience, you need to semi-manually (dpkg -i) convert the transitively-essential set, as otherwise apt will either throw its hands up or propose "remove world" as a solution. > Yes, but that still says: > > A full backup is also strongly recommended Duh. That'd be true even if it was a supported, well-tested operation. > I think a proper procedure should involve a script that: > > - is packaged in Debian; I doubt we can make one and have it in unstable before Xmas (the NEW freeze). > - checks whether the hardware it's running on has all the hardware > requirements for the new architecture (i.e., in case of armel to > armhf, can support the ARM ABI required by armhf; or in case of i386 > to amd64, is a processor that supports the x86_64 ABI), and produces a > proper error message in case the required support isn't there; Done! This is exactly what "arch-test" is for. > - is properly tested to work in (almost) all situations; Ha ha ha! > - is a properly supported way to move from one ABI to another. > > We currently don't have anything remotely like the above, and I think we > should. Here's my very early WIP: https://github.com/kilobyte/crossgrade It does only a bunch of checks, compares versions, builds and installs the essential set but doesn't go anywhere further. It also tries to reinvent the wheel in order to be resilient wrt partially aborted upgrades, I now realize I could have considered apt-perl libraries "essential" so they'd always work. And it's not like crossgrading is easily possible anyway: Unpacking libpam-modules:amd64 (1.1.8-3.3) ... dpkg: error processing archive /tmp/apt-dpkg-install-afa8lY/0-libpam-modules_1.1.8-3.3_amd64.deb (--unpack): trying to overwrite shared '/usr/share/man/man8/pam_exec.8.gz', which is different from other instances of package libpam-modules:amd64 At least my recovery code works properly, and after manual dpkg --force-overwrite /var/cache/apt/archives/libpam-modules_1.1.8-3.3_amd64.deb it resumes and succeeds until the end of implemented part. Then there is the multiarch interpreter problem. > [1] save that, I think, at the time multiarch didn't exist yet. Yes, > this was an "interesting" experience :-) Even for release architectures, binNMU versions are often not in sync. When you want something second-class (most of my crossgrading at home was to and from x32), multiarch works only in theory not practice. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11