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

Manas Saksena msaksena at marvell.com
Thu Jul 12 00:13:18 UTC 2007


Tom "spot" Callaway wrote:
> On Wed, 2007-07-11 at 15:51 -0700, Manas Saksena wrote:
>> Note that this is not a secondary architecture issue, per se. From
>> what
>> I can tell, the OLPC-Fedora distribution is already doing this within
>> the Fedora infrastructure. 
> 
> To an extent, yes, although, they're still following the Fedora
> Packaging Guidelines.
> 
> I'd be very interested in the guidelines that you feel you might need to
> break/ignore. :)

Packaging guidelines may be the wrong term. But, you often need to do
surgery (and sometimes a deep one ) to packages when you are trying to
squeeze functionality into a 4MB flash (or 16, 32, 64MB -- whatever).
At other times, you want to have tools (much like pilgrim, revisor,
etc.) that can ensure that whatever hacked up distro you end up creating
can be re-created automagically from your package repository (and, have
some resilience when packages get updated etc.).

For e.g.,

Lets start with the simple stuff. Many systems will have busybox, and 
will want to have a custom busybox config.

If you use glibc, you will almost certainly not want much of the stuff
that glibc carries. People might want to build against uClibc. Or, maybe
eglibc (www.eglibc.org). Both have them require a config file that may
be customized.

Maybe you have an application that needs openssl library. But, you
probably dont want to carry along everything else that the openssl
package provides. You almost always want only a subset of the files
that a package provides (although, this can be often hacked by some
post-processing, but you lose the package level integrity then).

(Virtually all packages will need to be hacked up this way when you
are operating under serious footprint constraints. And, BTW, footprint
in embedded/consumer devices means money -- so it matters an awful lot
to device manufacturers).

The locale stuff tends to be a big bloating thing and much of that may
not be needed in many cases.

Maybe you will have a custom init scripts package.

Sometimes you may want to change configure options for a package so
that it doesnt build with pam, or ipv6, or kerberos -- if you are
not going to need it.

Maybe you want to have a small footprint package db on target (e.g.,
something like ipkg).

Some of these, if they are deemed to be broadly useful, can be pushed
into mainstream fedora distro. Others will inherently end-up being
device specific since each device has to make its own unique tradeoff
of footprint and functionality -- a problem that desktop/server distros
generally dont have to worry about.

Etc.

Regards,
Manas





More information about the fedora-devel-list mailing list