David Woodhouse wrote:
2. One srpm which generates multiple crosses. This might be in the
form of one package for the Fedora mesh, another for all mips targets,
and so forth. The realm of when somebody wants to be a cross-arch-czar
or there is some technical reason to bunch them together.
I am having doubts this can work, either, because different
architectures/target OS aren't necessarily in a shape to be using the
same sources.
It definitely don't apply to embedded targets, which tend to require
different versions on different architectures.
We really don't want to pander to this. If an architecture cannot work
with a current toolchain, then we should just ignore it until the
toolchain is fixed. They can get it working upstream, or they can sod
off.
I think you on the one side and I and Ralf on the other side are talking about
different things, let me try to clarify. I believe you are talking about cross
building the Fedora distro to run as a replacement distro on embedded devices,
in which case I agree with what you say above.
However I (and Ralf to some extend to AFAIK) am talking about building
executables to run on an embedded platform using the manufacturer provided
distro for that platform. For example with the gp2x (a handheld game device /
video player) there is a distro in onboard FLASH and you can insert an sd-card
with your own applications.
In this case completely different rules apply.
Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel
next... and then we'll have to hurt them.
No we won't (be shipping their hacked kernel) as that is already in the device,
we are "merely" shipping a toolchain (+ headers / libs needed to compile /
link) to build applications to install into an already existing OS/platform.
3. One srpm which generates packages for a single cross, like Hans's
arm-gp2x-linux-package effort
IMO, this is the only viable approach. It bloats the repos and requires
some effort to assure packaging consistency when targeting several
architectures/OSes, but it's basically what I am doing.
This would be a little nicer once we move to git and can just pull
changes from Jakub's 'master' Fedora toolchain packages.
Again this is not Fedora-Fedora cross this is Fedora-XXXX cross, where XXXX
migh not even be Linux (it isn't in Ralf's scenario), so Jukub's Fedora
packages are about as much "master" packages as mandrake's, suse's or debians.
For starters a completely different version of some of the major toolchain
components may be used, in which case its madness todo this a a patch on top
of Jakub's specfile, because 90% of jakubs specfile would get replaced.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
