Hi,
I would like to propose a change in the rpm provides/requires handling of libs and binaries.
Right now, we use on arm the architecture to distinguish between hard and soft fp abi. This results to the fact that armv7l is complete incompatible to armv7hl due to the rpm architecture compatibility list (is this true everywhere?)
This is IMHO technical wrong. For example an rpm with a static build soft-fp binary should be installable on a hard-fp system. The kernel and the hardware does support it and it would just run. But furthermore this will make it also impossible later to have mixed systems.
What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64 world did go. Declare i686 backward compatible from x86_64, but to extent the provides and requires with an extension. So a hf binary will still require a hf lib.
A patch for rpm which should do this is attached, but I have not tested it, I have to admit. The reason is that want to discuss it here first, because this has a big impact: It would suddenly make the old armv7hl rpms not compatible anymore with the new ones.
So, I would like to here if you share my POV here in general. And secondly, if you see a chance at all to do this switch.
I promise to take care to push such a patch to rpm upstream, if you want it.
thanks adrian
PS: I have not evaluated how the NEON VFP world fits in here.
On Mon, 23 Apr 2012 20:20:27 +0200 Adrian Schröter adrian@suse.de wrote:
Hi,
I would like to propose a change in the rpm provides/requires handling of libs and binaries.
Right now, we use on arm the architecture to distinguish between hard and soft fp abi. This results to the fact that armv7l is complete incompatible to armv7hl due to the rpm architecture compatibility list (is this true everywhere?)
at least for Fedora its on purpose we do not want to support multilibed 32 bit arm systems.
This is IMHO technical wrong. For example an rpm with a static build soft-fp binary should be installable on a hard-fp system. The kernel and the hardware does support it and it would just run. But furthermore this will make it also impossible later to have mixed systems.
While in theory you can run hfp and sfp on the same system at the same time, it really does not make a lot of sense to do so. there is not a whole lot of proprietary software for arm, what is there should be easily rebuildable for hfp. the only use case i have heard that somewhat makes sense is video drivers. Vedors should be rebuilding those for hfp.
What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64 world did go. Declare i686 backward compatible from x86_64, but to extent the provides and requires with an extension. So a hf binary will still require a hf lib.
A patch for rpm which should do this is attached, but I have not tested it, I have to admit. The reason is that want to discuss it here first, because this has a big impact: It would suddenly make the old armv7hl rpms not compatible anymore with the new ones.
So, I would like to here if you share my POV here in general. And secondly, if you see a chance at all to do this switch.
I promise to take care to push such a patch to rpm upstream, if you want it.
thanks adrian
PS: I have not evaluated how the NEON VFP world fits in here.
for fedora we have armv5tel armv6l and armv7l for sfp and armv7hl and armv7hnl for hfp. armv7hnl is for neon optimised builds.
I have to be honest that patch is a horrible hack and completely wrong. marking hfp libs as 64 bit is not at all correct. we soon will have real 64 bit arm, the way to truely support what your proposing would be to make gcc and glibc multilibed and use something like /usr/libhfp/ for %{_libdir} on hfp certainly not /usr/lib64/. A big issue with what your done comes to supporting cleanly arm64 what the rpm arch will be depends on "uname -m" but i fully expect that libs will go into /usr/lib64 for consistency with other 64 bit arches however at least in fedora we dont plan to support 32 bit hfp and 64 bit on the same system, but a really good time to have brought this up would have been a few weeks ago, when we were discussing moving the hfp linker and made things multilibed to support your use cases. What are you use cases? other than it being you can do it?
Dennis
Am Montag, 23. April 2012, 14:24:03 schrieb Dennis Gilmore:
On Mon, 23 Apr 2012 20:20:27 +0200 Adrian Schröter adrian@suse.de wrote:
Hi,
I would like to propose a change in the rpm provides/requires handling of libs and binaries.
Right now, we use on arm the architecture to distinguish between hard and soft fp abi. This results to the fact that armv7l is complete incompatible to armv7hl due to the rpm architecture compatibility list (is this true everywhere?)
at least for Fedora its on purpose we do not want to support multilibed 32 bit arm systems.
This is IMHO technical wrong. For example an rpm with a static build soft-fp binary should be installable on a hard-fp system. The kernel and the hardware does support it and it would just run. But furthermore this will make it also impossible later to have mixed systems.
While in theory you can run hfp and sfp on the same system at the same time, it really does not make a lot of sense to do so. there is not a whole lot of proprietary software for arm, what is there should be easily rebuildable for hfp. the only use case i have heard that somewhat makes sense is video drivers. Vedors should be rebuilding those for hfp.
But do you want to keep this incompatible for sure all future?
What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64 world did go. Declare i686 backward compatible from x86_64, but to extent the provides and requires with an extension. So a hf binary will still require a hf lib.
A patch for rpm which should do this is attached, but I have not tested it, I have to admit. The reason is that want to discuss it here first, because this has a big impact: It would suddenly make the old armv7hl rpms not compatible anymore with the new ones.
So, I would like to here if you share my POV here in general. And secondly, if you see a chance at all to do this switch.
I promise to take care to push such a patch to rpm upstream, if you want it.
thanks adrian
PS: I have not evaluated how the NEON VFP world fits in here.
for fedora we have armv5tel armv6l and armv7l for sfp and armv7hl and armv7hnl for hfp. armv7hnl is for neon optimised builds.
I have to be honest that patch is a horrible hack and completely wrong. marking hfp libs as 64 bit is not at all correct
Hey, don't blame my poor patch, he lives just for documentation for now;)
Frankly, the current solution is a cruel hack to me. It abuses the architecture compat list for something what it was not supposed for. And it makes it impossible for all packages for all future.
The ABI is about soname dependencies. So the compatibility belongs there and not to hardware features of the CPU.
. we soon will have real 64 bit arm, the way to truely support what your proposing would be to make gcc and glibc multilibed and use something like /usr/libhfp/ for %{_libdir} on hfp certainly not /usr/lib64/.
The patch has not yet anything todo with any pathes. It would just extent the soname symbol in rpm provides/requires in whatever path it lives. And you can combine it with 64bit extension.
So, I would like to keep the path discussion out here.
A big issue with what your done comes to supporting cleanly arm64 what the rpm arch will be depends on "uname -m" but i fully expect that libs will go into /usr/lib64 for consistency with other 64 bit arches however at least in fedora we dont plan to support 32 bit hfp and 64 bit on the same system, but a really good time to have brought this up would have been a few weeks ago, when we were discussing moving the hfp linker and made things multilibed to support your use cases.
Sorry, but better late then never. However, I think it is just the next step. The runtime linker path is one thing important for .deb and .rpm, but this is just important in the .rpm world. But it would be nice if we can still stay compatible in our world of course :)
What are you use cases? other than it being you can do it?
I do not want to close the door for being able to do multilib installations ever. Even though we will not have it with out first release either.
bye adrian
-
Adrian Schröter -
Dennis Gilmore