Fedora Board Recap 2007-JUL-31

[Manas Saksena]

Jesse Keating wrote:
> On Thu, 02 Aug 2007 18:45:00 -0700
> Manas Saksena <msaksena at marvell.com> wrote:
> 
>  > So, what is needed is a recognition that this is a valid use-case that
>  > the Fedora project benefits from. And, that the world is more than x86
>  > systems, using grub, running from hard-drive, etc. So, you dont
>  > restrict their use unnecessarily. And, if that is done, then the
>  > derivative distros can add the capabilities to these tools and push
>  > them back for everyone to benefit from.
>  >
>  > Along the same lines, the advantage of fedora for me is that in my
>  > local package repository, I only have to make changes if/when
>  > necessary. And, I can ride on the common package repository. So, for
>  > Fedora-ARM, I want the base repository to be identical to the Fedora
>  > repository. And, then, I want to be able to derive from it and create
>  > custom distributions. So, all that is needed is to not make this
>  > unnecessarily difficult. And, it is exactly what the OLPC project is
>  > doing.
> 
> My question would have to be then, how are we getting in your way?  

There are patches that we need to apply to packages that enables them
to build on ARM. Most of these are trivial. And, they have been sitting
in bugzilla for a while. See the ARM tracker bug for pointers to these.

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

If we can get these patches applied, we can move onto building packages
for ARM per the secondary arch proposal. This simplifies our life, as
we then have to only worry about failures (after a package initially
builds).

There are a couple that are more difficult. They are worthy of a more
open discussion. For e.g., GCJ does not work on ARM today. We have a
patch that disables that and goes on with life. When gcj on arm works
on upstream, we can enable it again, and move on with life. Or, glibc
upstream has a glibc-ports tarball that carries support for ARM, and
some other architectures. We have a patch that adds the port tarball
to glibc to build for ARM and it has been refused by the maintainer.

See:

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

A slightly more friendly attitude their would be most welcome :-)

> I
> speak for myself but I know the feelings of many, and we /absolutely/
> wish to see derivatives made of Fedora.  More than just "I cut up the
> packages this way!".  Actual changes.  Cases we haven't thought of
> before, things we've been too afraid to try.  We're doing things to
> make this easier, like a new campaign to make it even easier to swap
> out our Fedora branding for more generic ones or your own.  

Good to know :-)

> What else
> can we do to foster this desire to play with the bits and make your own
> distribution?

A few things come to mind as things evolve in the future...

1. The VCS discussion should explicitly recognize this use-case. So,
    it should be possible for someone to clone the fedora src repo, and
    create derivatives from there, while staying synced up to the
    fedora repository.

2. As the compose tools evolve, hopefully they will not carry too much
    of an x86/PC class system bias. For e.g., revisor/wevisor are based
    on kickstart. I havent looked closely at it, but at first glance it
    seems to have too much of that bias. I dont know whether these are
    fixable or not. It would be useful, if using the same set of tools
    (with appropriate modifications) I can create, for e.g., jffs2 file
    system images.

3. It is useful to have Fedora packages stay close to upstream. And, if
    there is a need to put a desktop or server bias to them (by modifying
    them significantly from upstream sources) then maybe these should be
    considered in the same way -- i.e., as derivative distros of a base
    Fedora distro.

Regards,
Manas