@berolinux Just to be clear, I -have- a customer who has asked for armv8
WITHOUT NEON/VFP. This was obviously in the embedded space, but the same
customer is saying that it's not for compatibility, but is actually a 32-bit
'armv8' processor. (No 64-bit support..) I have no idea if those claims are
true or not, as I've not directly worked on that processor. Thus the mass
confusion continues.
But I agree with you, all aarch64 CPUs I have seen include all of the
prescribed hardware as indicated by the spec. There may be some instruction
scheduling differences, but so far the instruction set has been consistent and
compatible.
But with that said, I agree with what @n3npq mentioned above. Having these
indicates as part of the package 'name' (other then for human readable
purposes) really no longer makes sense. Between compatibility frameworks,
emulators, etc... the system and users should be able to specify compatibility
and priority and just 'go from there'. Same with package generation. It
would make my life easier (using RPM in embedded systems) to get rid of this
rpmrc notion for anything more then 'human readable'.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378942526
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
