[04:45] <OvenWerks> Eickmeyer: interesting. I guess I didn't expect the application to go so far :)  Feel free to try changing the -W to -S
[04:47] <OvenWerks> Eickmeyer: I don't think we can do anything about the purge because the user will not use installer to remove packages, they may use apt or software may remove something so it can install something else... Which is another thing we don't check for
[04:47] <OvenWerks> So that would be two bugs:
[04:48] <OvenWerks> 1) Allow installing of a removed package.
[04:49] <OvenWerks> 2) warn user if something they have installed will need to be removed to allow installing the new sw choice
[04:49] <OvenWerks> (mean while don't warn them it it is being removed because the new package is a "replaces")
[04:50] <OvenWerks> extra points for reading their mind and interpereting what they want even if they don't know what tha means...  ')
[18:13] <Eickmeyer> OvenWerks: I determined changing -W to -S to be ineffective. The whole problem is that dpkg keeps the record in its cache unless purge is used to uninstall. 
[18:13] <Eickmeyer> So, it's possible that dpkg can't even be used in this case.
[18:14] <Eickmeyer> A warning would be good, but I wouldn't include it except in a manpage or in a wiki. If we do add uninstall option to -installer, we should use purge to ensure that it can be detected as uninstalled.
[18:14] <Eickmeyer> That said, there's gotta be a way. Synaptic and aptitude figure it out.
[18:54] <OvenWerks> Eickmeyer: I would suggest that in most cases, someone might install one of the packages inside the meta and remove it rather than the meta itself.
[18:54] <OvenWerks> Eickmeyer: I would also guess it is possible to not install the meta at all... but rather just it's depends
[18:57]  * OvenWerks thinks installer is about to get somewhat more complex...
[18:57] <Eickmeyer> OvenWerks: This is true, but not all of the packages listed are metas.
[18:58] <Eickmeyer> Either way, if we add the uninstall option, it ought to use purge.
[18:58] <OvenWerks> yes
[18:58] <Eickmeyer> And, perhaps it'll get more complex, but we can worry about that when going Python.
[18:59] <Eickmeyer> It's actually as easy as "apt-get remove {metapackage} --purge}
[19:02] <OvenWerks> if you wish to add remove we would have to show what is removable. It starts to get to showing all the packages inside the meta like the iso install does.
[19:02] <OvenWerks> we need to know that a package has been installed or removed and how it has been removed.
[19:03] <OvenWerks> if we remove/purge or not is not that big of a deal at that point
[19:04] <OvenWerks> There may be good reasons to remove/no purge too. Such as removing the ubuntu version to replace it with an upstream version where keeping the config would be advantageous
[19:23] <Eickmeyer> This is true.
[19:24] <Eickmeyer> Although, in my experience, purge doesn't remove anything from ~/.config, so if it's a user-level config, that doesn't get removed.
[19:27] <OvenWerks> Eickmeyer: I guess anything the application writes after install is too hard to track
[19:28] <Eickmeyer> Indeed. So long as it's not acting as root, it's untrackable and confined to ~/.
[19:29] <Eickmeyer> Untrackable for dpkg, that is.
[19:33] <OvenWerks> There must be a way for any package to find it's status
[19:33] <OvenWerks> installed, removed, purged
[19:37] <OvenWerks> have you looked at the output of -s instead of -S?
[19:37] <OvenWerks> It still doesn't return a 1/0 but it is parsable
[19:46] <Eickmeyer> When I posted -S I meant -s. :S
[19:52] <OvenWerks> I think -s would work if it was properly parsed, it can't just be used as a substitute for -W
[19:54] <OvenWerks> With -W it was enough just to look for output or not, with -s we have to look for the Status: line and parse that.
[19:56] <Eickmeyer> Yep.
[19:56] <Eickmeyer> That's over my head.