[maemo-developers] Application manager category view proposals

[From: Andrew Flegg]

On Tue, Oct 28, 2008 at 11:33 AM, Ryan Abel <rabelg5 at gmail.com> wrote:
>
[forcing packages to comply with the "definitive" package list]
>
> The reason I like doing this Application Manager-side is that it forces
> compliance even for stuff not going through the autobuilder or Extras. This
> prevents both Nokia and 3rd party repositories from being evil and
> corrupting the category view.

Indeed, that's a very strong argument for it.

> apt pulls in a lot of data from the repositories when it does an update
> anyway, so why not pull in the authoritative list (including section names,
> encoded icons, i18n and anything else that's relevant) from
> repository.maemo.org during these updates? Enforcement is done in the
> Application Manager but doesn't require the Application Manager to be
> updated to update the section list.

I like this idea. Three things concern me (and not just specifically
about this approach):

    1) Will we want to change the package list that often? If there're
       occasional changes, pushing a new Application Manager release
       (or a hildon-application-manager-categories-data package) should
       be straightforward with SSU.

    2) When the package list changes, how much involvement will Nokia
       want? If "not much", can the community support all the i18n
       translations required.

    3) Is worrying about this just overcomplicating things for a
       situation which may never occur?

Having thought about it a bit more, I think there are 3 realistic scenarios:

    1) Force the Application Manager to do it, based on a simple rule
       like having an i18n label defined.
    2) Force the Application Manager to do it, with an external package
       defining the metadata.
    3) Force the Application Manager to do it, sourcing the metadata
       from *.maemo.org

In all 3, I think there's a case for a setting which ignores this.
Then, if someone is selling tablets with a bespoke environment, they
can still push updates from their own repository which only applies to
their walled-garden users, not general mainstream end-users.

Any other solution I can think of, or have seen discussed, has a
number of drawbacks which may push developers away from Extras.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
maemo.org Community Council member