Hey,
Allow me to fork the discussion into a plaform/fset cleanup subthread.
On Wed, Aug 20, 2008, Mitsutaka Amano wrote:
- 40_fsets.patch
Thank you for your a lot of information. I understand they are
specification of UME.
Well, I'm not sure: basically the fset concept duplicates information
which is already available in Ubuntu in the form of meta-packages.
It's only useful to name some group of packages when the names differ
across sets of repos IMO.
This fixes the fsets contents to install the proper packages and use
meta-packages for as much data as possible for Ubuntu fsets. I think
this should be merged upstream as otherwise people creating images
using your MIC or Ubuntu's MIC will get different results despite
selecting the same config.
IMHO the fsets in MIC are quite a mess ATM; they are listing a lot of
packages with no clear way to assert the rationale behind them.
Instead of multiplying the convenience fsets, I would personally
recommend simplifying them and simplifying platform usage as well.
I think we should have one platform per set of repositories; for
instance:
- "Ubuntu MID hardy": Ubuntu hardy .debs + ubuntu-mobile hardy ppa .debs
- "Ubuntu MID intrepid": Ubuntu intrepid .debs
- "Moblin 2": Moblin's "Stable" .rpms
I *don't* think we should have a platform per package architecture;
instead, there should be a platform default (e.g. lpia for Ubuntu and
i586 for Fedora); if necessary we could provide a way to override
architecture for each project, but is anyone building for other arches
than these?
Additionally, we should:
* Stop having platforms per hardware architecture: the same
repositories are used for McCaslin and Menlow .deb packages, I see
no point in maintaining menlow-* and mccaslin-* *platforms*; we
already maintain per device *fsets*
* Stop having hardware-specific platforms such as netbook-*: the .debs
or .rpms are again in the same repositories, so I see no reason for
* Drop the "Stack" fsets: CrownBeach-Full-Mobile-Stack,
* CrownBeach-Full-Mobile-Stack-with-Proprietary,
Moblin-CrownBeach-Full-Mobile-Stack,
Moblin-CrownBeach-Full-Mobile-Stack-with-Proprietary,
Samsung-Full-Mobile-Stack,
Samsung-Full-Mobile-Stack-with-Proprietary, Zi9-Full-Mobile-Stack,
Zi9-Full-Mobile-Stack
Instead, we should only provide per-device config packages (and that
should also disappear over time) and the "stack" fsets should be
GNOME-Mobile OR Ubuntu-Mobile OR Moblin2 etc. corresponding to a)
device specific packages -- usually only a single package and b)
choice of stack packages; typically the Ubuntu-Mobile fset would
probably be "ubuntu-mobile, ubuntu-minimal" or something along these
lines
* Drop the "Core" fset: I don't think there's any such thing as the
core; "ubuntu-mobile" should depend on packages it needs, the same
goes for GNOME Mobile etc.; if a choice needs to be made, the name
of the project making the choice should be clear: Moblin2-Core,
Moblin2-Desktop, Moblin2-Netbook etc. For the same reasons, we
should drop Core-Dev, Build, Developer-Tools, Ubuntu-Kernel,
Traditional-Desktop, Technology-Integration-Testing, Ubuntu-Staging,
X, X-Dev etc.
IMO fsets should have a standardized name and provide "stacks", or
support for a particular device. I would expect device support to be
available on all platforms (e.g. "Samsung-Q1U", "CrownBeach") and
stacks to be available on all or some platforms (e.g. "GNOME-Mobile"
available everywhere and Ubuntu-Mobile available on Ubuntu platforms).
We should limit fsets and platforms to a minimum IMO.
Ultimately, I think users should be stating that:
a) I want to build against platform "Ubuntu intrepid" or "Moblin 2"
=> select platform in platform drop down
b) I want to use software stack "GNOME Mobile" or "Ubuntu MID"
=> add fset for this stack in fset list
c) (optional) some of my target devices need device-specific packages
=> add fset for this device in fset list (e.g. "Samsung Q1U")
What do you think?
I don't think this requires much if any *code* changes to MIC; it
mostly means cleaning up of data definitions. Dropping a lot of old
stuff, reducing duplication, making things simple and obvious is how I
see it.
(I would like to add support for Ubuntu intrepid when we can settle on
this.)
Cheers,
