[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: fedora for generic crosscompile

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]