http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures

[Manas Saksena]

Jeff Spaleta wrote:
> On 7/11/07, Manas Saksena <msaksena at marvell.com> wrote:
>> I agree. But, it is not necessary unrealistic to allow derivative
>> distros under the Fedora project umbrella.
> 
> I think it is necessarily unrealistic for that to happen when you take
> into account
> branding policy considerations.  If the bits be wrapped up are not
> under the directly accessible via the centralized fedora codebase
> thing (cvs or whatever comes after it) then you simply cannot expect
> that collection of software to be able to be called Fedora.  Its
> unrealistic that this situation is going to change over night, even
> with new technical bits that make it easier for people to actually
> produced derived collections.

Fair enough. I dont really expect anything to change in the near future.

What I am saying is that you can creating a branding notion that
captures the essence of "derived from" without diluting the original
brand. If done right, this should enhance the Fedora brand. Whether
or not that is done is upto the people who make these decisions in
the Fedora/RedHat hierarchy.

Every one derives from Linus' kernel tree and creates their own custom
Linux kernel. But, they are all still Linux kernels. And, they dont
dilute the "Linux" brand.

>> And, it is certainly fine for us to do these outside the scope of the
>> Fedora project umbrella. Fedora is used as an upstream for many embedded
>> distros already. Our goal is to make it easy for the various embedded
>> ARM distributions (including the ones we create ourselves) to make use
>> of the Fedora-ARM as the upstream.
> 
> Uhm, is are current examples of packaging level problems that package
> maintainers need to address for packages to work on ARM?  As compared
> to... upstream codebase issues that upstream needs to patch?

I am not sure I understand fully. Hopefully, this will make it clear.

Most upstream software runs fine on ARM. And, where we have issues, we
try to get them fixed in upstream codebase.

We have a few packaging issues in Fedora -- these are Fedora issues,
not upstream code issues. These are filed in bugzilla. You can see
these at:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418

For Fedora-ARM, we would need these to be addressed, so we can build in
the Fedora infrastructure. This falls under the scope of the Secondary
Architecture proposal.

The other packaging issues that I am talking about are more to deal with
customizing for a specific footprint/functionality tradeoff. So, that
kind of packaging tradeoffs need to be handled "locally" (i.e., by the
person/team assembling that custom distribution). These are the derived
distros that are outside of the Fedora-ARM project -- which is fair.
Some of it might have been useful as a deliverable within the Fedora-ARM
distro (e.g., inclusion of cross-compilers), but from the discussion,
that is not likely to be the case either. So, we will keep that outside
of the Fedora-ARM distribution as well.

Manas