Platforms and Fsets cleanup

[Loïc Minier]

Hi,

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,