Comment 1 Ryan Abel 2008-08-18 04:55:28 UTC

I was tempted to mark this one as DUPLICATE, since there are a lot of older
bugs relating to this (I don't think I found all of them while I was searching,
either), but I'd rather use it as the real bug, since it's much clearer about
the problem and covers the whole issue.

So, I think I have a possible solution to this issue that might be acceptable
for Nokia. Obviously, these items may need to be updated with an SSU push, so
having osso-software-version depend on them is the easiest path to accomplish
this. The problem is, it doesn't leave users a clean option for removing
optional cruft without removing their ability to receive SSU updates (and
opening them up to a very high probability of reboot loops if they attempt an
apt-get upgrade without osso-software-version installed).

What if Nokia were to ship two packages that represent the whole of the system?
osso-software-version-rx*4, which depends on the required system packages and
osso-software-version-rx*4-optional[1], which depended on the commercial
installer packages (Gizmo, Rhapsody, Skype) and the bundled documentation and
media packages. Then when a user wants these packages removed, they remove
them, and osso-software-version-rx*4-optional in the process, meaning they
don't get stuck with them again with each SSU push and don't have the SSU
system broken for them. Users that don't remove them receive updates to them
like normal, with Nokia just having to update
osso-software-version-rx*4-optional in addition to the normal one.

This would allow users to remove non-core packages (we can argue about what
"core" means, I suppose--some people might not consider Modest "core"--but I
think we can definitely agree that installer dummies and big bundled media
files aren't that), freeing up space and freeing their tablets (from commercial
software).

Clearly this is a solution that can't be pounded out overnight, but can we at
least consider it?

[1]This does assume that this arrangement would be acceptable to the providers
of Nokia's bundled commercial software, but forcing commercial products on
users is quite an Evil thing to do in the open source world. Maybe an
osso-software-version-rx*4, an osso-software-version-rx*4-optional (which
includes the bundled documentation and media files) and
osso-software-version-rx*4-commercial?

Comment 2 Marius Vollmer 2008-08-18 14:12:23 UTC

(In reply to comment #1)
> Clearly this is a solution that can't be pounded out overnight, but can we at
> least consider it?

Yes, we should think of something.  I'd say (without too much thinking) that
the best option is to make "apt-get dist-upgrade" work.

From a Nokia point of view, something either is part of the OS, or it isn't. 
The OS does not have optional parts.

However, the device contains more than just the OS, and one can argue that
currently the OS contains many packages that should be moved out of it.  The
packages you list are good examples, and one might even think about going
further and even moving things like Modest and the browser out of the OS and
into their own modules.

Modules that are not in the OS will appear with their own entries in the
Application Manager, and the user needs to update them explicitly.  On the plus
side, you can then remove and reinstall these modules individually.

In other words, the parts that you want to be optional would no longer be
considered to be part of the OS at all, they would behave like 3rd party
packages.

Sounds good?

Comment 3 Ryan Abel 2008-08-18 14:35:30 UTC

(In reply to comment #2)
> In other words, the parts that you want to be optional would no longer be
> considered to be part of the OS at all, they would behave like 3rd party
> packages.
> 
> Sounds good?
> 

This definitely sounds good for the clearly optional stuff (3rd-party
installers, bundled "extras"). The tutorial home applet is probably a good
example for how this could work, correct?

Sounds like a bit of a can of worms with stuff like Modest and MicroB, though.
It does fit with the upgrade practices used by desktop operating systems (Apple
pushes Safari updates separately from the OS proper, as does Microsoft with
Internet Explorer and Linux distributions with Firefox), but if they're
expected to stand on their own two feet outside of the OS (as desktop
applications are), then something will have to be done to address their
respective branding since "Browser" and "E-mail" don't really lend themselves
to indentifiability and uniqueness (though I suppose Nokia could choose to
ignore the issue and stick with the generic names).[1] Modest is a bit better
off than MicroB as far as this goes since at least the whole application
actually has a real name, and half of it isn't closed source (Nokia, make it
easy for us and just open source the whole thing so we can call it by a real
name? :)).

Anyway, the very optional stuff should be fairly straightforward, but the
details of stuff like MicroB and Modest will have to be examined closely.


[1]http://wiki.maemo.org/Task:Maemo_brand#To_Be_Defined

Comment 4 Andre Klapper 2008-08-18 15:14:01 UTC

So who's the person "in charge" of rethinking this? Marius? :-/

Comment 5 Marius Vollmer 2008-08-19 21:05:13 UTC

(In reply to comment #4)
> So who's the person "in charge" of rethinking this? Marius? :-/

I'd say our release management cabal, which doesn't include me.

Comment 6 Ryan Abel 2008-09-29 22:55:44 UTC

One of the more immediate issues with this implementation is that it insists on
pulling in megabytes worth of useless PDFs as part of update process, which
greatly reduces the likelyhood of an easy upgrade for many users, since the
limited amount of internal NAND means most users will be running near the limit
most of the time, and that extra 14MB or so (most of the time, the
pre-installed-documentation-rx*4 package accounts for the majority of an
updates size) makes a big difference in the installability of the update and
the quality of the user experience.

They are available online at nokia.com, are they not? So if a user voluntarily
chooses to remove them, then  they can certainly retrieve them from there if
they wish. Forcing 14MB of PDFs down people's throats with each and every
update is just a terrible plan.

Comment 7 Quim Gil 2008-09-30 09:25:54 UTC

This bug will be solved one day, I bet. I'm still figuring out who and when,
though.  :)

It could come either from improvements around
http://wiki.maemo.org/Seamless_Software_Update or as one of the steps to
achieve http://wiki.maemo.org/Objective:Maemo_variants

Or it could come as a decision with easyfix in a meeting with the right people. 

Marius, any insight on this will be helpful since you know the technicalities
and changes in our release process this would imply.

Comment 8 Eero Tamminen 2008-09-30 09:42:48 UTC

> that extra 14MB or so (most of the time, the pre-installed-documentation-rx*4
> package accounts for the majority of an updates size) makes a big difference
> in the installability of the update and the quality of the user experience.

The file system compresses the files with LZO, so from the file system the PDF
files take in reality <10MB[1].  Still a big problem though as JFFS2 keeps the
whole file system structure in memory which means that it will use more memory
when the file system is fuller (and significantly more for files that are
open). System using more memory means that applications have less which means
that they will abort() more easily[2].


[1] You can test this with something like:
    time tar -cv /home/user/MyDocs/.documents/ | lzop > test.tar.lzo
    du -k test.tar.lzo

[2] Glib and everything based on it like Gtk will abort if memory allocation
fails, there's not really much that can be done about that, all major UI
toolkits work like that (handling alloc failures reasonably would increase code
size significantly and explode amount of work needed. Not several times, but
(several) magnitude(s) more if one wants to do it properly).

Comment 9 Marius Vollmer 2008-09-30 15:01:08 UTC

(In reply to comment #7)
> Marius, any insight on this will be helpful since you know the technicalities
> and changes in our release process this would imply.

Three things should be done, IMO:

 - All packages should be fixed so that "apt-get dist-upgrade" works.

 - Nokia's releases should be modularised: it should be possible to release
   and upgrade the core OS independenly from the Browser, etc.  Users should be
   allowed to do simple configuration management on the device: they should be
   able to remove the browser if they don't want it without losing updates to
   the core OS.

 - Meanwhile, while we wait for Nokia to get its corporate head around the
   first and second point, Maemo should consider producing its own
   configurations, maybe spearheading the modularisation idea.  Users can
   decide to follow the Maemo releases instead of Nokia's by pointing their 
   devices to a repository on maemo.org instead of the one on 
   tableteer.nokia.com.  The Maemo community would maintain that repository
   as it sees fit; by copying packages from tableteer.nokia.com into it 
   whenever Nokia makes a new SSU release, and producing its own meta packages.

   (It's probably not a good idea to use the Maemo Extras repository for this,
   but I think it would be a good idea to just merge Maemo Extras into the
   Maemo SSU repository.  This would effectively create a Maemo distribution.
   Source packages will be a problem, tho.)

And along with taking care of the back end, I'd like to address the front as
well: give us the option to exclude certain unwanted files, like the
unnecessary product docs (I only want US English).  That could be part of the
locality settings (time, region) in the wizard.  I'll bet that forcing a
solution for that enables an easy solution for the overall issue... at least
where product docs are concerned.

I personally think that letting some of the packages I listed show up in the
installable/removable packages list in the package manager would solve this
problem perfectly.  Remove the packages from the dependencies list of the
osso-software-version-rx34 metapackage, and put them in section "user" so the
package manager shows them.

indeed, only the items that are required for the basic boot and use of the
device should really be required by the ssu update, the rest should be left
outside of it to save both size and failure points.

that the browser, mail or docs fail to update should not "brick" a device,
ever!

they should just fail, and let the user fix it later, if possible.

from the description i found on a forum thread, it sounds like the ssu setup
have things in common with the american housing economy. house of cards on a
foundation of sand anyone?

nokia need to stop thinking about the tablest as closed devices with a set
collection of features/functions. they are pocketable linux computers, not some
cheap phone the user will abuse and throw away after a year for a new, more
shiny one.

the linux base will give these things a very very long lifespan, and nokia just
have to learn to like it...

Comment 13 Ryan Abel 2008-10-02 01:40:21 UTC

(In reply to comment #9)
>  - Meanwhile, while we wait for Nokia to get its corporate head around the
>    first and second point, Maemo should consider producing its own
>    configurations, maybe spearheading the modularisation idea.  Users can
>    decide to follow the Maemo releases instead of Nokia's by pointing their 
>    devices to a repository on maemo.org instead of the one on 
>    tableteer.nokia.com.  The Maemo community would maintain that repository
>    as it sees fit; by copying packages from tableteer.nokia.com into it 
>    whenever Nokia makes a new SSU release, and producing its own meta packages.
> 

Based on this and jott's earlier ideas on the subject, I've gone ahead and
started laying out a basic proposal on the wiki.[1]

As far as moving packages from tableteer to another repository, this seems like
it might be a legal gray area for the proprietary stuff (bme, mce,
tablet-browser-ui, and more particularly the 3rd-party stuff like flash). Nokia
has passworded the upgrade repo, so clearly we can't just copy things wholesale
into a clear repo and be OK.

So, we're looking at a number of possible solutions:

1. The free stuff is maintained in a community repository (either Extras on
something else on maemo.org), but the non-free stuff is still fetched from
tableteer. The problem here is users in Red Pill or using apt-get being exposed
to unsanitized updates before the community can react to a new SSU push.
Probably not a _big_ issue, but it does increase complexity. Of course, this
could be solved rather simply by Nokia giving the community a few days lead
time to react before an update is actually pushed.

2. Same as above, except proprietary stuff (perhaps just 3rd-party proprietary
stuff that Nokia does not control the licensing of) is provided in a non-free
section in tableteer, so users wont be exposed to all of the updates packages.

3. Everything is simply copied wholesale with the agreement of Nokia legal
(likely not acceptable).

>    (It's probably not a good idea to use the Maemo Extras repository for this,
>    but I think it would be a good idea to just merge Maemo Extras into the
>    Maemo SSU repository.  This would effectively create a Maemo distribution.
>    Source packages will be a problem, tho.)
> 

Yeah, I don't think Extras is the right place for it either, but Niels is doing
so well with his repository-killing crusade that I want to consider the options
there a while before we decide anything for certain.

[1]http://wiki.maemo.org/Task:Maemo_Community_distribution

Comment 14 Eero Tamminen 2008-10-02 10:26:14 UTC

> The file system compresses the files with LZO, so from the file system
> the PDF files take in reality <10MB.

I think this pre-installed content might actually be the reason why the SSU
fails for some people.  As the file system is compressed, you cannot just
calculate how much space an update requires, it needs to be tested and that
requires quite a bit of iteration.

I think we internally test this by filling the rootfs before SSU update is
tried.  However, that test results may not valid if user has manually removed
some of things that are pre-installed and that SSU depends from.  If they're
not removed in the internal testing, those files would be just replaced on SSU
update i.e. no additional space is needed. If user removed them, more 10MB
space is used...

As a conclusion: SSU shouldn't update any content that user can easily remove
without removing the corresponding package.  I think currently this concerns
only pre-installed content.

Comment 15 Quim Gil 2008-10-02 12:12:54 UTC

> [1]http://wiki.maemo.org/Task:Maemo_Community_distribution

As said in maemo-community, this falls in the 2010 Agenda's
http://wiki.maemo.org/Objective:Maemo_variants

Therefore, the "framework" is commonly approved and we "only" need to do some
work on it.

Comment 16 Marius Vollmer 2008-10-02 13:53:11 UTC

(In reply to comment #13)
> (In reply to comment #9)
> As far as moving packages from tableteer to another repository, this seems
> like it might be a legal gray area for the proprietary stuff (bme, mce,
> tablet-browser-ui, and more particularly the 3rd-party stuff like flash). 

Yes, very true, I didn't think of this before.

Another way out could be to use the 'SDK' releases as the source for a
community distribution instead of the SSU releases on tableteer.nokia.com. 
These releases have a much better defined legal status than what is on
tableteer.nokia.com.

However, the 'SDK' releases are probably not in a shape either that allows
deriving a complete community distribution from them.  That would be an action
point for Nokia, to make this possible.

Comment 17 Ryan Abel 2008-10-02 14:49:27 UTC

(In reply to comment #14)
> > The file system compresses the files with LZO, so from the file system
> > the PDF files take in reality <10MB.
> 
> I think this pre-installed content might actually be the reason why the SSU
> fails for some people.
>

More than a few people it seems, actually. Failure of this package to properly
install prevents all other packages from being configured which seems to
variously mean "unable to use wifi" to "reboot loop".

(In reply to comment #16)
> (In reply to comment #13)
> > (In reply to comment #9)
> > As far as moving packages from tableteer to another repository, this seems
> > like it might be a legal gray area for the proprietary stuff (bme, mce,
> > tablet-browser-ui, and more particularly the 3rd-party stuff like flash). 
> 
> Yes, very true, I didn't think of this before.
> 

I think we should consider the two types of non-free packages separately. The
non-free Nokia packages that Nokia controls the licensing of (bme, mce,
tablet-browser-ui, applets) and the non-free 3rd-party packages that Nokia does
not (Flash)

> Another way out could be to use the 'SDK' releases as the source for a
> community distribution instead of the SSU releases on tableteer.nokia.com. 
> These releases have a much better defined legal status than what is on
> tableteer.nokia.com.
> 

Unfortunately it's become clear that SDK releases wont correspond to Maemo
releases, so this leaves us high-and-dry for the more minor updates, as well as
eliminating lots of proprietary parts of the OS that are required for it to
work (bme, mce, etc.).

> However, the 'SDK' releases are probably not in a shape either that allows
> deriving a complete community distribution from them.  That would be an action
> point for Nokia, to make this possible.
> 

A non-free section in the tableteer update repo that contains 3rd-party
proprietary packages, a community repo that contains all of the sanitized free
packages, and Nokia licensing their own non-free packages in such a way as to
allow us to distribute them separately would be the optimal setup (well, a
complete community mirror with all packages is the optimal setup, but clearly
not a workable solution).

Barring Nokia allowing use to use their own non-free packages, a community repo
with all free packages and a section of the tableteer (separate from the
regular section SSU updates use so it doesn't interfere with regular users)
with only non-free packages is the next best solution (I just talked to Marcell
about this option and he seems fairly positive about it).

Possibly this non-free tableteer section could wait to be updated until the go
ahead is given from the community packagers (unless Nokia makes it really easy
and gives us a heads-up on updates a few days before they're actually pushed)?

Comment 18 Marius Vollmer 2008-10-02 16:02:45 UTC

(In reply to comment #17)

> I think we should consider the two types of non-free packages separately. The
> non-free Nokia packages that Nokia controls the licensing of (bme, mce,
> tablet-browser-ui, applets) and the non-free 3rd-party packages that Nokia
> does not (Flash)

I would classify them into "freely-distributable" and "non-distributable".  I
hope that some of the non-Nokia-owned binary-only packages are actually
freely-distributable.

> > Another way out could be to use the 'SDK' releases as the source for a
> > community distribution instead of the SSU releases on tableteer.nokia.com. 
> > These releases have a much better defined legal status than what is on
> > tableteer.nokia.com. 
> 
> Unfortunately it's become clear that SDK releases wont correspond to Maemo
> releases,

I hope that this can be fixed.  It is not helping anyone to not synchronize SDK
and device releases.  Ideally, a SDK release and a device release will be the
same thing, and SDK and device will use the exact same repositories.  But,
yeah, that's probably a project of its own.

> A non-free section in the tableteer update repo that contains 3rd-party
> proprietary packages, [...] 
> Possibly this non-free tableteer section could wait to be updated until the go
> ahead is given from the community packagers [...]

This sounds like a good plan.

In the beginning, we can treat the whole of the SSU repository as if it would
be non-redistributable.  That is, the Maemo community distribution would point
to a repository on tableteer.nokia.com (or maemo.org/catalogue, which is the
same thing) that is dedicated for this purpose, and Marcell would copy the
current SSU repo over to that repo upon request.

Comment 19 Andre Klapper 2008-10-02 16:24:15 UTC

(In reply to comment #18)
> > Unfortunately it's become clear that SDK releases wont correspond to Maemo
> > releases,

See bug 3747 for this topic.

Comment 20 Marcell Lengyel 2008-10-02 18:04:53 UTC

(In reply to comment #18)
> > A non-free section in the tableteer update repo that contains 3rd-party
> > proprietary packages, [...] 
> > Possibly this non-free tableteer section could wait to be updated until the go
> > ahead is given from the community packagers [...]
> 
> This sounds like a good plan.
> 
> In the beginning, we can treat the whole of the SSU repository as if it would
> be non-redistributable.  That is, the Maemo community distribution would point
> to a repository on tableteer.nokia.com (or maemo.org/catalogue, which is the
> same thing) that is dedicated for this purpose, and Marcell would copy the
> current SSU repo over to that repo upon request.

I would do it that way, to create a new community repository next to extras and
make a copy of the SSU repository on tableteer.nokia.com with all the real
packages minus the metapackages. The community repository would provide the
metapackages that have dependencies to the SSU packages on tableteer. This way
the SSU packages would remain on the same server (less work for me :)) but this
way two repositories are needed for the community distribution.

Comment 21 Marius Vollmer 2008-10-02 18:38:40 UTC

(In reply to comment #20)

> I would do it that way, to create a new community repository next to extras
> and make a copy of the SSU repository on tableteer.nokia.com with all the
> real packages minus the metapackages.

I don't think there is any harm in keeping Nokia meta packages.  It should be
simpler to just leave them in.

> [...]
> but this way two repositories are needed for the community distribution.

Yes, and I think this is a feature: some packages can only be distributed by
Nokia with appropriate access control (they are in the tableteer repo), and
Nokia will not allow other packages to be distributed (but distributing them
from maemo.org is fine).  So I think there is no way around having two distinct
repositories for a single distribution.

What about having a simple system where the community can request packages to
be copied around on tableteer.nokia.com?

We could have a project on garage.maemo.org, and a cronjob on the Nokia machine
will check a file hosted by that project for instructions.  Possible
instructions could be creation of directories, copying packages around and
deleting packages.

I'd be happy to help set this up.

Comment 22 Quim Gil 2008-10-03 09:06:29 UTC

We have now many related thread happening in different places. Please let's try
to have each discussion where corresponds, and also if possible concentrate on
first things first.

As I understand, this big deals with 2 issues:

1. Considering slimming down the list of packages involved in the SSU, taking
into acount all users. For instance, Flash won't go away, but pre-installed
content might be another story. I would keep the discussion in this bug in this
scope since the result is a bug that can be filed against the official
Diablo/Fremantle programs.

2. Considering ways for the Maemo community or power users to come up with
their own configurations, without loosing the beauty of SSU. This is not for
the average user, won't get official Nokia support and the Fremantle/Diablo
programs won't take it for their commitments. They are very interesting
maemo.org tasks though, in line with the 2010 Agenda, and they can get the
support and commitment of the Development Platform team (responsible of the
maemo.org infrastructure and the SDK releases). This discussion would be better
held somewhere else following the process for maemo.org tasks.

Comment 23 Eero Tamminen 2008-10-03 12:31:06 UTC

SSU shouldn't update/re-install anything that user can easily remove through
the UI, either from the Application manager (e.g. packages Map & Tutorial which
are quite large) or through File manager (e.g. pre-installed content files). 
If it does, I think that's a bug.

As to which of the packages are visible in the application manager by default
(i.e. uninstallable) in the future, I think that's where the community comes
into picture.  The use-cases and reasons for something being uninstallable
could be:
- Application that user doesn't use, which package is large and other device
functionality doesn't depend from it.  Uninstalling it will free disk and
applications menu space for other applications
- User choice: community (eventually) provides a well tested and (mostly)
better replacement for the default installed application

In both cases the application should be re-installable from the default
repositories in case user wants it back.


I think in future more of the pre-installed applications should be
uninstallable and community can help in finding these applications by just
testing what breaks if a given app is removed and how easy it's to replace them
with something else.

Maybe the process could work like this with the maemo development community:
- Community wants something to be replaceable or not in SSU
- Community does initial testing of how well things work without it and
proposes it to Nokia with the results of their testing
- If Nokia agrees with the reasoning and internal testing agrees with the
results, application is changed to be uninstallable and removed from the SSU
dependencies
- Community can check out the new SSU updates before normal users get them

Quim/Marius, how does this sound?

Comment 24 Quim Gil 2008-10-03 12:39:09 UTC

(In reply to comment #23)
> Quim/Marius, how does this sound?

Sensible!

Comment 25 Marius Vollmer 2008-10-03 12:59:03 UTC

(In reply to comment #24)
> (In reply to comment #23)
> > Quim/Marius, how does this sound?
> 
> Sensible!

Very! :-)

(But I would use the word "removable" instead of "uninstallable", which could
also mean "not installable"...)

Comment 26 Eero Tamminen 2008-10-03 16:24:46 UTC

Added URL to ITT post summarizing issues with SSU (packages it installs).

Comment 27 Andre Klapper 2008-10-28 15:31:35 UTC

So is this something that will be worked on for Fremantle? (/me looks at
Marius)

Comment 28 Marius Vollmer 2008-10-28 16:09:18 UTC

(In reply to comment #27)
> So is this something that will be worked on for Fremantle? (/me looks at
> Marius)

Not by me, sorry.

Comment 29 Ryan Abel 2008-11-24 00:20:34 UTC

(In reply to comment #28)
> (In reply to comment #27)
> > So is this something that will be worked on for Fremantle? (/me looks at
> > Marius)
> 
> Not by me, sorry.
> 

Well, is there any chance we could get that person to come here?

Comment 30 Andre Klapper 2008-12-09 23:16:47 UTC

Ville: Can this be considered for Fremantle?

Comment 31 Ville Lavonius 2008-12-10 11:53:43 UTC

(In reply to comment #30)
> Ville: Can this be considered for Fremantle?

Certainly.  We have an SSU-meeting on Friday, and the new usecases for
Fremantle are on the very top of the agenda.

Comment 32 Andre Klapper 2009-01-02 13:42:31 UTC

(In reply to comment #31)
> (In reply to comment #30)
> > Ville: Can this be considered for Fremantle?
> 
> Certainly.  We have an SSU-meeting on Friday, and the new usecases for
> Fremantle are on the very top of the agenda.  

Ville, any news you could tell us?

Comment 33 Andre Klapper 2009-03-24 14:22:35 UTC

> (In reply to comment #31)
> > > Ville: Can this be considered for Fremantle?
> > 
> > Certainly.  We have an SSU-meeting on Friday, and the new usecases for
> > Fremantle are on the very top of the agenda.  

Ville, any news here wrt Fremantle?

Comment 34 Andre Klapper 2009-05-05 17:36:11 UTC

Ville, can you answer the last question, please?

Comment 35 Quim Gil 2009-05-21 14:38:27 UTC

There is some progress here, yes.

This is an update and not a confirmation: it looks like at least the small tiny
apps and shortcuts to installers will be indeed removable. We need to look
closer to more complex apps like Browser or Email client since their
architectures have some dependencies that need more attention. Then some
"system apps" like e.g. File Manager would be there only to stay, even if some
power users would like to use alternatives.

All in all the trend is that Nokia needs to provide good defaults but not force
them to users and allow them to substitute them by alternatives. Whether we can
complete this mission in Fremantle only or we need to carry some things to
Harmattan is still to be seen.

(In reply to comment #35)
> There is some progress here, yes.
> 
> This is an update and not a confirmation: it looks like at least the small tiny
> apps and shortcuts to installers will be indeed removable. We need to look
> closer to more complex apps like Browser or Email client since their
> architectures have some dependencies that need more attention. Then some
> "system apps" like e.g. File Manager would be there only to stay, even if some
> power users would like to use alternatives.

While the ability to substitute alternatives for things like the browser or
email client sounds interesting, I really only had concerns about two key types
of packages: proprietary bits like flash and the installers, and huge bits like
the pre-installed-* media packages.

> All in all the trend is that Nokia needs to provide good defaults but not force
> them to users and allow them to substitute them by alternatives. Whether we can
> complete this mission in Fremantle only or we need to carry some things to
> Harmattan is still to be seen.

That sounds promising.  Thanks for the follow-up.

Comment 37 Quim Gil 2009-09-14 08:30:01 UTC

This problem is fixed in Fremantle, with the exception of the Flash Player -
see below.

Maemo 5 comes without installers. You see icons for installed software and then
you can install via Application Manager, Maemo Select, maemo.org/downloads,
etc.

There is no "promo applet" anymore.

Pre-installed content is flashed separately in the internal memory card and is
not affected by software updates.

When it comes to applications, the first release will have still a monolithic
metapackage managing all apps including e.g. Sketch or Mahjong. The current
plan is to make those little apps also uninstallable. This feature would come
in a maintenance release.

Browser + Flash player will be there to stay, though. The browser accomplishes
the function of application, but the engine is also used as a platform
component by other apps. Flash Player cover a functionality demanded by the
vast majority of Maemo users and we consider it also part of the platform. The
power users willing to get rid of it probably can find a way.

Comment 38 Marius Vollmer 2009-09-14 11:03:14 UTC

(In reply to comment #37)
> Browser + Flash player will be there to stay, though. The browser accomplishes
> the function of application, but the engine is also used as a platform
> component by other apps.

This by itself is not a reason to not make the Browser removable.  If the
browser is removed but the engine is still needed, the engine will stay
installed of course.  If the engine later becomes unneeded as well, it will be
automatically removed then.  (If we set things up in the right way.  Some
changes to the Application manager might be needed to make this work reliably.)

> Flash Player cover a functionality demanded by the
> vast majority of Maemo users and we consider it also part of the platform.

You can make it part of the browser engine instead.

(In reply to comment #37)
> When it comes to applications, the first release will have still a monolithic
> metapackage managing all apps including e.g. Sketch or Mahjong. The current
> plan is to make those little apps also uninstallable. This feature would come
> in a maintenance release.

If I'm reading this right, it hasn't been actually implemented even internally
so isn't it a bit premature to resolve the bug now?

> Browser + Flash player will be there to stay, though. The browser accomplishes
> the function of application, but the engine is also used as a platform
> component by other apps.

As Marius says, inter-package dependendies should take care of that.  There's
no real need for osso-software-version-xxx to depend on the browser in addition
to those.

Comment 40 Quim Gil 2009-09-14 22:37:43 UTC

This report is about 'unnecessary packages' being tied to a system update. In
Fremantle the types of packages mentioned by the reporter are not tied to the
system metapackage anymore, except Flash that is considered 'necessary'. This
has been working for some months now in the internal releases.

Beyond what was requested in the initial report, but in line with the
discussion, Maemo 5 will make several applications independent from the system
metapackage. The specific list of apps is being discussed and will be
implemented in a maintenance release. The discussion is less about technical
terms and more about "what constitutes part of the Maemo experience"?

It looks like application like the browser, with Flash integrated, are part of
this experience and therefore it won't be offered as uninstallable in the
standard Maemo releases. I personally think that making all the "little" apps
is a progress good enough for Fremantle. If someone wants to go deeper probably
something deeper can be organized at a community level.

Since getting rid of the stock browser or other key apps has not been the core
of the discussion in this report, and since the reported issues are fixedd and
explained, I think it's fair te resolve this bug as fixed now. Please reopen if
you disagree.

(In reply to comment #40)
> This report is about 'unnecessary packages' being tied to a system update. In
> Fremantle the types of packages mentioned by the reporter are not tied to the
> system metapackage anymore, except Flash that is considered 'necessary'. This
> has been working for some months now in the internal releases.

Right, so the Diablo "unnecesary" packages (third-party installers and such)
will no longer be present in the official Fremantle image, and the third-party
apps will be un-installable independently of the rest of the system, but
uninstalling "official" apps will come later?  Sorry if I'm being thick, just
trying to understand the status of this.

> Since getting rid of the stock browser or other key apps has not been the core
> of the discussion in this report, and since the reported issues are fixedd and
> explained, I think it's fair te resolve this bug as fixed now.

If the situation is as above, sure.

Of course with the /opt (or whatever it ends up being called) partition and
UbiFS on the rootfs (so unused files don't also eat up RAM unnecessarily) this
is now less important.

Comment 42 Quim Gil 2009-09-15 12:07:25 UTC

(In reply to comment #41)
> uninstalling "official" apps will come later?

Yes, as said: 

When it comes to applications, the first release will have still a monolithic
metapackage managing all apps including e.g. Sketch or Mahjong. The current
plan is to make those little apps also uninstallable. This feature would come
in a maintenance release.

(In reply to comment #40)
> This report is about 'unnecessary packages' being tied to a system update. In
> Fremantle the types of packages mentioned by the reporter are not tied to the
> system metapackage anymore, except Flash that is considered 'necessary'. This
> has been working for some months now in the internal releases.
> 
> Beyond what was requested in the initial report, but in line with the
> discussion, Maemo 5 will make several applications independent from the system
> metapackage. The specific list of apps is being discussed and will be
> implemented in a maintenance release. The discussion is less about technical
> terms and more about "what constitutes part of the Maemo experience"?
> 
> It looks like application like the browser, with Flash integrated, are part of
> this experience and therefore it won't be offered as uninstallable in the
> standard Maemo releases. I personally think that making all the "little" apps
> is a progress good enough for Fremantle. If someone wants to go deeper probably
> something deeper can be organized at a community level.
> 
> Since getting rid of the stock browser or other key apps has not been the core
> of the discussion in this report, and since the reported issues are fixedd and
> explained, I think it's fair te resolve this bug as fixed now. Please reopen if
> you disagree.

As the original reporter, I don't mind seeing this issue closed now.  I find it
disappointing to hear Flash considered part of the platform, but given that
decision I understand keeping the dependency.  The rest sounds resolved.

One question: does this include the stock images/videos/manuals that take up a
lot of space?  (Though with the N900 having 32GB, I don't know how much I care
anymore. ;) )

Comment 44 Andre Klapper 2010-04-12 13:11:43 UTC

(In reply to comment #42)
> When it comes to applications, the first release will have still a monolithic
> metapackage managing all apps including e.g. Sketch or Mahjong. The current
> plan is to make those little apps also uninstallable. This feature would come
> in a maintenance release.

Quim, is that still the plan? Asking because of bug 9891.

Comment 45 Quim Gil 2010-04-12 13:17:47 UTC

(In reply to comment #44)
> (In reply to comment #42)
> > When it comes to applications, the first release will have still a monolithic
> > metapackage managing all apps including e.g. Sketch or Mahjong. The current
> > plan is to make those little apps also uninstallable. This feature would come
> > in a maintenance release.
> 
> Quim, is that still the plan? Asking because of bug 9891.

That was indeed planned but was cancelled. The most annoying problems were
solved by separating content from apps. But then separating apps from platform
was still complicated for many apps in Fremantle, there was some extra work in
packaging and localizations and it was considered not so relevant.

fwiw Harmattan/MeeGo brings a well layered architecture and a process to handle
system updates autonomous of applications...