Jeff Spaleta wrote:
On 7/11/07, Manas Saksena <msaksena@xxxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
