Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
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
Reply to: