I went by the list and my votes are included in the attachment. Dunno which would be the best way to share these votes? Some external service or manually editing files which seems bit involved?

Anyway here are few highlights and my comments regarding them:

1. adobe-flashplayer - PURGE - Do we really need this for anything?
2. docpurge - PURGE - Is this necessary?
3. Various games - PURGE - they can be included in separate metapackage (Games) like discussed earlier.
4. Mediaplayer - REMOVE - Installable later if the user needs it by separate metapackage (Multimedia/Media Playing). Dunno how the depends go so needs to be checked first. Do we have a .deb for this purpose?
5. Nokia Maps - Remove - This could be included in a metapackage (Maps & Navigation). Do we have a .deb for this purpose?

What do you think of the above? Was there something I missed or is there something that cannot be removed so "widely"?

Your updates have been added to 1st post. I figure that's the easiest place for people to follow along.

I'm a big fan of removing stuff, and re-adding it to other meta-packages.

Yes, PR1.3.1 contains only security fixes for certifiate management. Specially blacklisting certificates and blacklist database of comodo CA certs...

Of course PR1.3.1!

This is the part of the thread where I will bring up de-optification and movement towards a more "universal" linux style filesystem. Currently, the way I do things, I use a bindmount technique. After purging unwanted .debs and upgrading to the kernel that I use, I perform my bindmount tricks. Now, You might ask, why not do the bindmount tricks after a full upgrade? Because it WILL fill /, and that's not cool. The point is to free / and make it have the least amount of crap on it. Also, this is where a Universal Argument is going to take place. "Stryngs, your bindmount techniques, they're not FHS!" I'll touch on that argument, after I describe what I do.

I would love to have bindmounted the whole FS, but, I don't know the "guts and boot processes" of the n900 like some of you smarter folks; so, I chose directories which I figured "safe" to do, and went with it. Luck worked out in my favor and my n900 boots correctly. I've always wondered, what happens if we bindmount /etc, /bin, etc.. etc.. etc.. So the story goes, when it comes to boot, some stuff is going to have to be "visible" to the bootstrapping process (wrong word?), while I've managed to hack together a solution for my purposes, I don't know if the bindmount technique would allow the Operating System to work if I went 100% bindmounted. I'd love to hear it from some of the smarter folks, and let me know what's up. Okay, Enough blabbing, here we go:

mkdir -p /home/rootfs_bind/var/lib
cp -ar /usr /home/rootfs_bind
cp -ar /sbin /home/rootfs_bind
cp -ar /lib /home/rootfs_bind
cp -ar /root /home/rootfs_bind
cp -ar /var/lib/dpkg /home/rootfs_bind/var/lib

After copying over the files, I modify /etc/event.d/rcS-late with the following changes:
mount --rbind /home/rootfs_bind/usr /usr
mount --rbind /home/rootfs_bind/sbin /sbin
mount --rbind /home/rootfs_bind/lib /lib
mount --rbind /home/rootfs_bind/root /root
mount --rbind /home/rootfs_bind/var/lib/dpkg /var/lib/dpkg

Reboot and p00f! Now, with the combination of the above, and my naked pymaemo-optify concept, installing a .deb works as the author of the .deb had intended, the files, in the / of the .deb, they actually go WHERE they were intended to go, not some /opt voodoo black magic. Also, as a side benefit (An intended one I might add...) You can grab ANY armel or all based .deb, and simply dpkg -i it. No having to worry about, "Oh noes, is this going to fill /?" Now, I'm not hating on optification; I just think the concept can be done smarter.

Alright, I said there was going to be an argument, so let's discuss it. FHS, also know as the Filesystem Hierarchy Standard. Standards, that what this whole concept is anyways, so it's a darn fine point to talk about. I've heard in chat over the past couple days about moving /usr to eMMC. Also, as has been brought up, if a .deb was built AS IT SHOULD HAVE BEEN, it too will follow the FHS, and thus, / will never overflow. So... The FHS argument trumps my bindmount technique 100%. The problem? I've yet to find a written and documented solution. Folks speak of it, but, in this instance, we need pixels on screens to form a coherent set of processes that We, the Community, can follow; otherwise it's just some homebrew technique, and one of the many reasons I cry out for the Unification of our community. SO... if you are one of those who possess the knowledge of how to move /usr over to eMMC, safely and efficiently, PLEASE... respond to this and layout the steps, from start to finish.

Lastly for this topic, there exists in my mind, some concerns with what I currently use. I'm not a kernel developer, I'm a hacker; I go with what I know and what I'm willing to try; however, the n900 can be delicate. As well, it's old and no longer in production; if I flash flash flash flash flash... Eventually, I might wear out my hardware, and then I no longer have my n900... Yes, I can buy another one, but why experiment if we don't have to. So here is my question; specifically I direct this question towards Pali. Based on what I've done, with my bindmount hack, How does this affect when you next release a new kernel? Since, at some point in the boot process, I'm guessing that /home/rootfs_bind/usr is NOT /usr, and /usr is really /usr, then the changes and updates, that have occured since original bindmount inception won't show during the bootprocess, at least not until rcS-late kicks in and mounts things. In other words, based upon what I've done, do I need to, in order to "properly and safely" upgrade the kernel, unmount my bindmounts, perform the kernel upgrades, copy the appropriate NEW files to their bindmount location and then re-bindmount?

Okay, hopefully I've confused everybody at this point. Heck, I confuse myself thinking about bindmounting sometimes. So.... Thoughts?

p.s. When I update the CSV next, I will respond to your additions and such. I like them!

someone is saying to remove Nokia Maps? Gawd!

yes, from the base-install. So, a lean 'n mean, more standard Linux minimal install, with meta-packages for different areas of function, such as "Navigation".

I tried removing Nokia Maps in the past. There were no surprising dependencies so it went pretty well. The only problem was that removing Maps did not remove the Contacts integration so tapping on an address in Contacts still tried to open Maps on that address. I suspect removing Nokia Maps properly may involve more effort than anyone is prepared to invest.

Agreed pichlo...
there will be some ugly spots I'm sure.
On the whole the idea of what the op proposes is sound and sane.
Having meta-packages somewhat similar to say [roughly] Bodhi ...
works well for it...
may work very well for us.
a single streamlining...
easy to implement and use..
universal one-stop shop does make sense ...
especially now with all the flavours...
and the need to be canny about what you are doing and how to do it.
I think cutting the Nokian [Gordian] knot is a good idea.
But as pichlo does sanely mention...
some things it might be better to just leave alone [ie- maps] and work around them [no harm in it] ...
making the work on this more ...um...expedient.. time-wise in effort...
to bring this to the community in a timely fashion.

anyone have link for PR 1.3.1 firmware ?? i want to download it.