Re: Preventing the mixing of armhf packages
+++ Mike Thompson [2012-04-26 00:18 -0700]:
> I'm making good progress on a Raspberry Pi flavored port of Debian armhf and I
> hope to have a significant number of packages built within a few weeks. As has
> been discussed within these threads is that while armv6 armhf packages can be
> co-mingled on a armv7 armhf system (why you would want to do that is another
> matter), a method must be found to prevent the casual installation of armv7
> armhf packages on an armv6 armhf system. With the wrong packages, such a
> mistake could prevent a system from functioning.
> My question is this. What's the best, user friendly way of minimizing the risk
> that a user of Debian armhf on the Raspberry Pi would accidentally set their
> sources.list file to point to the official armhf repository and start pulling
> down armv7 packages that will potentially corrupt their system?
> My thoughts were to not include the installation of the official Debian
> repository public keys on the Raspberry Pi, but only include the keys for the
> alternative Debian armhf repository that contains packages safe for the
> Raspberry Pi. This wouldn't prevent someone from installing the official keys
> on their own, but it would at least present a barrier the user would have to
> intentionally pass over.
> Is this a reasonable approach? Or, are there better ways of tackling the same
The right way to do this is with HWCAPS bits to identify whether the
hardware can run v7 binaries and for dpkg to refuse to install stuff
that won't run.
This is how it works on x86:
with HWCAPS for cmov and cmpxchg16b
However I'm not sure the arm HWcaps list:
actually covers the extra v7 instructions. You could probably use the
VFP3 CAP as a proxy on PI, but it may be better to define an actual
'has v7 ISA' bit)
So to use this mechanism would need the kernel to check for only-on-v7
instructions and set/not-set the bit. Then arrange for packages to
have needed HWCAPS set in metadata for dpkg to check.
As this data is not already present in everyone else's packages
you'd be best just adding it for the PI packages you've built.
Which of course means you could actually use any old item of metadata
'X-package-ISA:v6' and check that, refusing to install anything else,
rather than a properly general HWCAPS method. But doing it right would
be generalisable to many problems of this class (multimedia-optimised
libraries, with without/NEON etc).
You should be able to get some help in doing that as others have
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM