My above thought-dump not withstanding, last I checked, there were a lot of much more low-level components for which we did not yet have open replacements). Some are trivial (the CAL-area interfacing stuff, since libcal was succesfully reversed a year or so ago), and someone just needs to take the time. But some, as I understand it, are still a ways away from having replacements.

Well said @Mentalist. I favor you in all the points you said in your thought-dump. And I think your thought-dump needs a special thread.

@MentalistTraceur
Maybe part of your wall of text was more suited to this thread
http://talk.maemo.org/showthread.php?t=90862

clock-ui and camera-ui2 are in CSSU-T.
OMP isn't in CSSU so it can be compared to stock one with the same device to locate any bug reports, I believe.
If any package is found to be slightly buggy it should not go in to CSSU-S.

I don't think it's a good idea to merge system and extras packages, for starters its an extra layer of security and is used by HAM.
http://talk.maemo.org/showthread.php?t=93227

I still don't see an issue with sharing a fresh CSSU backupmenu backup from a trusted source.

Why hasn't Open Media Player yet replaced Media Player? I don't think it has issues and can be included in CSSU-T.

1. The backupmenu solution is a good idea too BUT I don't see any trusted source (or any source for that matter) providing it.

2. While the backupmenu solution is good, @MentalistTraceur's first point is not a bad idea either.

Thanks. If/when I get the time I'll read over it and contribute my thoughts there as well.

I agree that the default mindset should be 'fix bugs if you want to be allowed into stable repo', but I contend that at some point, the advantages of having the software outweigh the bugs that still linger. (An instance of that, to me, is that libre software with a few very minor corner case bugs is still a win over a hypothetically non-buggy closed one).

I spend a lot of time looking into computer security, and I must say: that's not adding any security.

I welcome you to explore how most big Linux distros manage their package distribution: You will find that for the most part, system packages coexist in the same repositories as completely-fluff packages - when they do segregate repositories its for organizational purposes (stability of updates expected in each repo, or Debian free/contrib/non-free segregated-on-principle repos), not security purposes.

Maybe this will explain better:
0. When apt-get downloads packages and (through dpkg) installs them, it runs as root: therefore, ANY package installed from ANY enabled repository has the SAME unbridled power/privilege on your system: ability to run arbitrary commands in the install and removal scripts as root.
1. Because of #0: Security in a repository is ensured by having the proper controls in place on what is promoted there, to keep bad/malicious software from having good chances to get into the repo, and the level of dilligence must be the same for all repos.
2. You have to understand: The segregation we have between "system" packages and the other packages, between the repos, and in how HAM handles the packages, is not inherent to the package management system. The underlying apt/dpkg stack is operating under the principles of points #0 and #1.
3. Because of #0 and #2: there is no security benefit to having separate repositories the way that we have them: the least-secure repo you use to install/update software dictates how secure your entire device is.
4. Between #2 and #3 we can conclude that: either we are confident all of our 'default' repos (incl. extras) are secure, in which case we can put system packages in any of them, or they are not secure, in which case we have a problem which is not in any way fixed by keeping some packages in another reposity.

In short, in the current way, packages in the extras repos CAN nuke and usurp and replace packages in the (C)SSU repos as is - if they want to do so maliciously, that's not a problem. But certain legitimate uses, as described in my last post, are made more difficult.

Now, as for HAM using it, maybe that's good, maybe not. I admit I don't know HAM's nuances, because I stopped using HAM within the first months of owning an N900 back in 2010 and never looked back. I used FAM for a while, then just gradually transitioned to directly using apt-get.

But from what I've heard I am not convinced that any HAM's deviations from how package managers work in the 'upstream' distros like Debian is how we should do things. I don't know of any deviation that I actually agree with off the top of my head.

For example, in the thread you link you discuss FAM's autoremove-by-default not being the best idea. I agree, but the only way it would actually break things is if packages were already buggy in their packaging (e.g. package A depended on package B but didn't declare it in its Depends field, then broke when package B was autoremoved, or maybe package C's prerm script deleted some file actually belonging to package D). If some of HAM's similarly non-standard behaviors allow badly-packaged packages to go unnoticed on a system where the user only uses HAM to manage packages, then that itself is a problem too.

Even without that though, I don't see what is wrong/missing in the standard apt/dpkg stack. I understand user-friendly/anti-stupid decisions like hiding system packages and actions like auto-remove behind some UI element (whether that be checkboxes or an 'advanced' menu or different views for different package categories, one of which is 'all', or whatever). But as far as the package management itself goes, the only differences I hear/know about, are ones that seemingly made sense for Nokia's goals of maintaining our phones are commercial product, but which don't seem to me to be best choices for a more general perspective of just having a nice distro for our phones.

After giving that package manager thread linked to a read-over, I see that the big differences HAM has are:
1. Domains
2. Some recovery if interupted (battery falls out while updating or something)
3. Loose scriptability (independent of the underlying deb package system's preinst/postinst/prerm/postrm scripts)

I put some (which was still a lot) of my thoughts there.