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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
