Michael Cree wrote:
As I have said before i'm strongly against the idea of using a new architecture name for a mere change of minimum CPU requirements. While it may reduce confusion it would mean that packages that should be able to be mixed won't be able to be and it would also mean no upgrade path for existing raspbian users.I would presume though that to be hosted at debian-ports a newarchitecture tag would be needed to avoid confusion with armhf.
I can't think of any bug reports as such. I've seen the odd person on IRC and the forums who has broken their system by doing that but it doesn't seem terriblly common.do you get many bug reports that result from people having added in armhf from Debian (or Ubuntu, etc.) into apt sources not realising it is not compatible with the Pi?
One thing we do is deliberately exclude the debian archive keyring from our repository specifically to discourage people from installing packages from debian.
We use a script which extracts the package and runs readelf on the contents. It's not perfect and it can suffer from both false positives (when armv7 code is present in the package but not required for it to work or where a binary is tagged as armv7 even though it doesn't actually contain any armv7 code) and false negatives (when a binary is not properly tagged or when a jit generates code at runtime) but it mostly does the job.And how do you detect armv7 specific cpu instructions when you buildon armv7 infrastructure?
Is it possible to somehow limit a chroot to trap on invalid armv6 instructions despite running on armv7?
Not that i'm aware of
No and I can't think of any way to do this within the framework debian provides.Or do you re-run test suites after successful builds on an actual Pi?