[fedora-arm] RPM available in the rootfs

Jon Masters jcm at redhat.com
Sun Jul 3 19:43:22 UTC 2011


On Sat, 2011-07-02 at 20:14 +0000, Dennis Gilmore wrote:
> > On Sat, 2011-07-02 at 13:59 -0400, Jon Masters wrote:

> > 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.

As I said, I understand why you parsed /proc/cpuinfo using the same
approach as the SPARC code. My point above is that it's better we
replace that with either parsing out the ELF section info on the RPM
binary so that we know we're actually running hardfp (that way, you can
even install softfp on hardfp systems and use whatever kernel you like -
the correct thing will happen based on the software environment).

> 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 thought one could still specify a target explicitly at build time? So
it'd be like all i686 systems defaulting to i686 but having the ability
to build for i386 if you explicitly tell them to.

[ addition: though perhaps using "buildtranslate" excludes that. And if
it does, then, ok we need another solution because yes we'll want armv7
hosts to be able to build packages for armv5 ]

> 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.

So I'm ok with reverting in F15 and upstream if you want :) I think we
need to keep this hack in the rootfs version for now so that it just
works (I don't want volunteers who come to help having to do anything in
addition to the instructions[0]), and then I'd like to replace the /proc
parsing with ELF parsing or similar if possible. We already link against
(I think, I'll check) enough deps to do that without increasing the
burden on RPM. But I guess we'll need to get Panu or someone to comment
on whether they mind having code that opens the ELF file and parses it.

Thanks for your hard work on this. I'm not criticizing :) My point is
more that we need to make sure things are easy for people who want to
help build stuff. If we need to rely on them having setup a bind mount
in /proc for binaries to come out the right way, it's one more way we
might not be able to benefit from their time helping to build stuff.

Thanks!

Jon.

[0] The fact that this *didn't* work out of the box with the rootfs and
that you, DJ, and others were obviously having to "do something" to make
it (rpmbuild) build correctly means you were doing something not in the
instructions. That's fine. Because you know what you're doing - it's the
standard Linux dilemma ("oh I just did this...and it was fine") but it
doesn't help someone who comes along and wants to help. We need to all
be using the stock rootfs in explicitly documented ways for bootstrap.




More information about the arm mailing list