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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux