[oe-issues] [Bug 2919] Create a distro for gumstix

bugzilla-daemon at tinman.treke.net bugzilla-daemon at tinman.treke.net
Wed Sep 5 09:47:48 UTC 2007


http://bugs.openembedded.org/show_bug.cgi?id=2919





--- Comment #13 from Richard Purdie <rpurdie at rpsys.net>  2007-09-05 02:47:47 ---
I'm not sure this discussion should be happening in a bugzilla and it should
perhaps move to the mailing list. I'll post this message here but I think there
are wider issues under discussion here and the mailing list would be more
visible.

I believe gumstix has a clear cut need for its own distro for the reasons Craig
mentions and probably others. I understand where Koen is coming from here as OE
has a history of people wanting to create their own distro simply to customize
packages or other things an independent distro is inappropriate for. I think
Angstrom needs to recognise people are going to need their own distro in some
cases though (omoko is another example). These need to be considered on a case
by case basis and some agreement on who will maintain the distro is an
important  part of that consideration, I'm guessing if gusstix cusomters are
using OE, bitrot won't be a problem though.

I think aiming to use angstrom as a base for distros such as gumstix is a good
idea and something we should strive for since it doesn't need to reimplement
everything angstrom does, just tweak it for a specific use case.

The pitfalls of an independent distro should also be stressed. The base gumstix
machine files should be independent of the distro or the images that are
produced. This means the machines should be useful on angstrom or any other
distro like poky or openmoko). The same applies to a lesser extent to the
images as an image is a collection of packages and should also work with any
distro too (within reason). I've asked Koen in the past to try and merge the
standard images with the angstrom images and this is something that needs
consideration as its currently setting a bad example.

I can certainly understand the need for making things simple to use for users
and you might want to look at how Poky does things in that regard for ideas. We
do give the users options there in the form of a well commented sample
local.conf and sane defaults but the three command setup process to build an
image might be attractive to you.

Regarding FSTYPES and machine conf files, it makes sense in some cases and less
sense in others. As an example, the update routines for an Akita always need a
jffs2 file so defaulting to jffs2 images makes sense for that machine. Its
something to consider on a case by case basis (and even in the akita case its
just a default and as with most things in OE, is overridable).


-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.




More information about the Openembedded-issues mailing list