[maemo-developers] [maemo-developers] extras repository

[From: Marius Vollmer]

"ext Carlos Guerreiro" <carlos.guerreiro at nokia.com> writes:

> Yeah. That's the way to go: proper archive management with something
> like DAK (we'll look into that at least for sardine and herring once
> there's some time) and a build system to go with it.

I think we are more in need of a clue than in need of proper
tools. :-)

Please allow me to ramble a bit:

Just deploying DAK doesn't automatically give you a sensible
repository layout or distribution landscape.  Actually, without
knowing too much about DAK, it might be that having to wrestle with
DAK itself will distract us and make it harder to see clearly where we
actually want to go.  (Hopefully I am wrong, the real Dakkers please
correct me.)

So, what would a sensible distribution landscape be?  I don't have the
experience to be authoritative here, but I think Ferenc is well on the
right way.

First, we should be talking about distributions and theirs components,
not so much about repositories.

[ Distributions are things like mistral, scirocco, sardine, herring;
  components are things like main, free, non-free, extras;
  repositories are things like http://repository.maemo.org/,
  http://catalogue.tableteer.nokia.com/
]

Then, the thing to realise is that we have two ways of looking at what
is going on, and they tug at each other: on the one side we have the
'traditional' model of releasing a monolothic OS image and a matching
monolithic SDK; this is how it looks to a lot of people inside Nokia,
I think.  On the other side is the 'traditional' Debian model of using
evolving repositories of packages where the packages are deployed in
the 'same' environment as they are developed, and the repositories are
the means of deploying new stuff; this is what people expect to be
happening when they see Scratchbox and apt/dpkg being used for maemo.

The situation where the "mistral" distribution is supported for the
SDK but not for the device is a good example: this situation looks
perfectly alright from the "OS image + SDK" point of view, but having
the thing break when you configure "mistral" on your device was a big
surprise for people who had the "one environment" view.

In my opinion, the "one environment" development model is vastly
better than the "OS image + SDK" model, assuming that we can make it
work.

And we _can_ make it work: the device and the OS running on it are
fully capable of being a development environment, there should be no
problem getting GCC running on it, etc.  The device just is too slow
and has too little memory to be a nice development environment.  Enter
Scratchbox: it's not an emulator to test the final software, but it's
an emulator for the development part of the environment on the device.

So I think we should be heading towards the "one environment" model.
The sardine distribution is already there, and the rest is quite
close.

I think we can actually copy the Debian model mostly verbatim, with
"unstable" for integrating significant changes, "testing" to represent
the most recent release candidate for the next release, and "stable"
for maintenance of the last release.

Roughly speaking, "sardine" would be "unstable", "herring" is the
first attempt at a distribution in "testing" state, "scirocco" is the
current "stable" and "mistral" is the stable release before scirocco.

One important point is that releases (that are 'stable') can evolve:
maintenance would be done by putting a new version of a package into
"stable".

Another important point is that distributions are designed to be
self-contained and all-encompassing: all packages whatsoever that are
meant to be used _with_ a certain distribution should be _in_ that
distribution.  That would include all 3rd party applications listed on
the Applications Catalogue wiki pages.

The distributions would be divided into components, and "extras" would
simply be one of those components.

The existing 'Tableteer' catalogue would turn into a component as well
(but it might continue to be hosted in a different way than "extras".)

The proprietary software that is added to a meamo distribution to make
the complete IT OS would also just be a component of the
distributions.  Ideally, this component will also be served from a
public repository, but maybe that is not possible.

It should be frowned upon for people to run their own repositories.
The only accepted way to distribute packages for maemo devices would
be to put them into one of the repositories on maemo.org.  This allows
the community to maintain them collectively.

In the ideal world, the Application Manaher would not have a
"Application Catalogues" dialog at all; it would only have a "Select
components" dialog.

[ There could also be a "Select distribution" dialog and once a new
  release has been made of the IT OS, people might choose to use it to
  select that new release and then the "Check for updates" view would
  let them do the upgrade.  (UI-wise it might be better to not put that
  functionality into the Application Manager, granted.)
]