fedora for generic crosscompile

[Manas Saksena]

Andy Green wrote:
> Brendan Conoboy wrote:
>> Ed Swierk wrote:
>>> That said, there is certainly room for both approaches, and getting
>>> even a small number of packages to cross-compile might be enough for
>>> many embedded applications.
>> Definitely.  For cross compilation, I picture a per-package flag in Koji
>> that marks it as cross-friendly or not.  There are certainly numerous
>> technical and social details to work out to making such a system work
>> and work equitably.  We're just getting started.
> 
> Well some areas to think about
> 
>  - The disparity in platform resources and power will be greater than
> ever before.  Choices made in ./configure switches that are the standard
> Fedora way can easily blow packages and dependencies out of scope for
> otherwise capable targets.  You can tie choices in configuration to the
> arch, but isn't it more interesting to imagine it is its own "bloat
> dimension", so weak x86 targets can be built for?  How about being able
> to specify multiple %build and Requires based on a new macro %_bloat.
> %_bloat = 10 is the normal supported Fedora traditional build with
> Kerberos everywhere and so on.  But the spec file can also define
> alternatives along the lines of %if %_bloat < 10  <alternative config
> args> %endif or %switch/%case (either requires a little extension to rpm
> AFAIK).  Only the default bloat level needs to be supported and shipped
> by Fedora to the extent it already is, folks can --rebuild to target
> lesser platforms fedgentoo style.  %_bloat=1 can even give you a busybox
> / uClibc based result if you want to max it out.  But to get started all
> the packages can just build the standard way without any conditionals.

While using a bloat dimension is interesting, I think it is too 
difficult to capture the full richness of feature/footprint tradeoffs 
using a single parameter like that.

Instead, the way I think this could be addressed is by:
-- providing a tool that makes it easy to rebuild packages with
    different configure flags
-- make it easy for folks downstream to fedora to rebuild fedora
    packages and fedora based custom distros using the above too.
-- make it easy for folks downstream to fedora to track upstream fedora
    changes, while maintaining local

In my experience, this kind of customization is best done when the 
feature/footprint tradeoffs are well-understood; i.e., when a root file 
system is being created for a specific device, and when both the 
functions to be supported by the device and the footprint constraints 
are well-understood.

Over time, you could see a bunch of sample device profiles -- each 
representing a customized root file system that is derived from fedora 
packages, but in a systematic, easy, and traceable manner. And, these 
can then become the basis of new device profiles.

You might want to take a look at "tsrpm" tool that was built by Chris 
Faylor (ex TimeSys) that allowed some of this for Fedora RPM packages 
using a mechanism called package hints. You can find more information 
at: https://crossdev.timesys.com/ (the site is pretty much dead, but 
there is useful information there). I have also cc'ed Chris.

>  - How to install foreign arch libs and -devel packages.  There is
> already a precedent in having i386 libs on x86_64 boxes but this is a
> bit different because the arch is REALLY foreign.  It will have to know
> to do some kind of --root= action if it sees you installing s390 libs
> into an i386 box, because you clearly don't want them going into the
> real /lib.

This is handled by tsrpm as well (among a number of other nifty features).

Manas