[fedora-arm] RPM available in the rootfs

[Dennis Gilmore]

> On Sat, 2011-07-02 at 13:59 -0400, Jon Masters wrote:
>> On Sat, 2011-07-02 at 05:15 -0400, Jon Masters wrote:
>> > On Thu, 2011-06-30 at 18:47 -0400, Jon Masters wrote:
>> >
>> > > Thanks to the hard work of many people (including Stefan's
>> contribution
>> > > this morning to get some of the final nss bits and RPM in place, and
>> of
>> > > course the groundwork put in place by DJ Delorie), we are now very
>> close
>> > > to having rpm and rpmbuild. I fixed a problem with digest support
>> > > earlier, we're just waiting on fixing the RPM macros/teaching RPM
>> about
>> > > armv7hl vs. armv7l, etc. in patches Dennis already has and will send
>> me.
>> > >
>> > > I'm hoping to get the remaining bits in place so that tomorrow's
>> VFAD
>> > > can be spent building actual RPMs. We'll need to start by rebuilding
>> > > what we have but in real RPM format, then work toward slowly getting
>> a
>> > > buildroot that we can use to rebuild everything again, and finally
>> do
>> > > one more build to have a full featured build environment. It would
>> be
>> > > awesome to get to a point tomorrow where we've got an armv7hl
>> binutils
>> > > binary RPM and its deps at least, with anything else being a bonus.
>> >
>> > Just as a head's up. I've changed the default build for all v7 systems
>> > such that we'll target armv7hl, unless it's otherwise set at build. I
>> > committed the change to redhat-rpm-config, and pushed up to F15.
>>
>> Since this came up on IRC, and I need to run, let me note:
>>
>> Note. I changed this for a *very specific reason*. Without this, and if
>> you don't have /proc explicitly mounted, RPM will default to armv5tel.
>> Since (at least for now), we have no business building armv5tel on armv7
>> systems, it's better to make sure nobody is building armv5tel.
>
> Really have to run...but just to add...
>
> I know it's good to bind mount /proc, it's probably a good idea anyway.
> I'm also not against agreeing to drop this patch, but I'm not in favor
> of dropping it just to support some theoretical ARM v7 system without
> hardfp. There is really, in reality, no such thing as non-hardfp v7 (as
> long as you do -d16, which we do). Therefore, I can see no harm in
> assuming armv7 means hardfp for the moment.
>
> Finally, I know sparc parses /proc/cpuinfo, so I see where the idea
> comes from, but as I mentioned in this case before, the correct thing to
> do is to use something intrinsic from the filesystem, such as the ELF
> sectional data on the RPM binary itself that says it was build hardfp. I
> would rather fix the patch not to rely on /proc information, however it
> is actually done. Anyway, we can debate, but I need to run!
>
> For now, at least, just cloning the repo on an armv7hl system will do
> the right thing for all actual systems that (will ever) exist.

As i said on irc making the change in the git tree for this would be ok,
but the change is wrong for general consumption,
parsing /proc/cpuinfo as my patch does is used to check for the existance
of cpu flags to determine capability, i.e. can we run a neon optimised
binary etc. though that should be in an ideal world detected at run time
and not at build time.

there is possibly many ways to skin the cat. what i see as wrong here is
that if you end up with rpm saying your on softfloat and the internal copy
of uname -m that rpm uses hasnt been rewritten to something indicating
that you are running with hardfp i t will try to build a hardfp binary. we
should be trying for softfp binaries the route we have gone with rpm has
been to keep hard and softfp separate and not parallel installable, what
this means is that in practice you can not install hardfp rpms on softfp
systems and vice versa.  with this change we then limit our building of
softfp binaries to armv5tel and armv6l systems only, i am sure we will
want to use some armv7 machines in the build pool for armv5tel binaries, 
users may also want to do the same thing.  while you can install either
stream of binary rpms into a chroot and it will work as you want it to and
expect it to. it would require special work in rpm to detect these cases
and allow the transaction to happen. maybe thats easier to do than i
expect. im happy to be proven wrong.

i dont disagree that having thins as you patched them in the git chroot is
ok. but i do disagree with making that change upstream in fedora as its
not going to help and will confuse those who do run softfp installs on v7
hardware for whatever reason. except in limited cases i do agree that v7
hardware should be running a hardfp install.

Dennis