Abstract of the thread: http://talk.maemo.org/showpost.php?p...1&postcount=17

I didn't want modest installed so removed it long ago and thus had to remove mp-fremantle-community-pr. Also, since then I've removed calendar-ui stuff (replaced with Qalendar). And my phone looks fine.
I don't really remember if I had had to apt-get install all the packages that should've been marked for autoremoval but except for that I didn't notice any major problems. I check every CSSU changelog for a new package and also sometimes run
to verify that I didn't miss something.
Is there a way to remove modest and calendar without removing mp-fremantle-community-pr? What other problems can it possibly lead to?

Also, I wanted to create a couple of packages like replace-calendar using info from http://talk.maemo.org/showthread.php?t=90942 and having Replaces: calendar, calendar-ui, etc
AFAIU it will also delete mp- package. Is it possible to make it work somehow?

CSSU itself:
* Needed for updating CSSU via HAM (+notification support in status area)
* Show CSSU version in control panel CSSU applet
* Store CSSU version string when kernel panic to mtdops (for reporting bugs & debugging)
(I do not remember if CSSU/Maemo using metapackage for someting else)

Other application can do:
* Check if CSSU is installed and act on this info
(but preferred way is to check version of specific package(s) - not metapackage)

Any normal way to get rid of modest without deleting mp-?

Normal = without deleting files directly?

no, there is no way.

What about calendar? Since it's closed-sourced it will be replaced eventually (I hope so, Qalendar is good enough already, I think). And AFAIU we need some separate package to contain the right /usr/share/dbus-1/services/com.nokia.calendar.service. And it must be replacing calendar packages.

So, can we please have some package no-modest and have mp-fremantle-community-pr depending on it or modest?

If that's possible I'll try to do all the needed work.

an excellent demonstration on why mp-*fremantle-*-pr is a defective design and should get replaced by something more sane in CSSU, long term but ASAP.

A maybe silly but obvious idea: why not remove all the dependencies from mp-community-pr and instead have according "apt-get install" lines for each package in mp-community-pr's postinstall script? We could even add some fancy checks of a well-defined file like /.mp-community-pr_exclude_packages, to allow user to explicitly _not_ install certain stuff she doesn't want to get touched by CSSU upgrades.

@int_ua: afaik HAM doesn't support "OR", and it's hard to come up with a definition how to handle such "OR" when it comes to installation of a new mp*, which of the alternatives should get auto-installed?
Maybe 1.5 years ago we had a CSSU public meeting where merlin and me introduced an alternative concept for this problem, which involved patching HAM to handle the problems that arise. Checking for "PROVIDES" properties as well could introduce a method to have alternatives of which one is mandatory. A similar thing has been done for H-E-N depending on a property provided by hostmode kernel, and aiui for thumb kernel and CSSU-thumb.

bottom line: often devels and users bitch about "CSSU doesn't allow XY to `go into CSSU`" - what they mean is adding XY to CSSU MP, but CSSU should get rid of MP and asking for adding even new stuff is reactionary.


/j

Which, in real world - considering amount of hands working on CSSU for real - results in limbo, that we neither get rid of mp-fremantle* nor get system upgrade packages (unreplaceable by other means, except for cp overwrite in postinst script - which is exactly why CSSU as separate repo got developed, to avoid such postscript ugly binary file replacements) incorporated into CSSU. See upstreamed and bugfixed busybox - for Maemo or CSSU, it exist in ancient and stripped version, while we have to install upgraded one via binary replacements.

Or theoretically great ideas like cssu-extra, that no one want to devote time on for >years (just because for all practical purposes, it's redutant, and manpower aspect comes again - there is always something better to spend time on, than this). No, don't even get me started on CSSU's package inclusion "policy" (buggy camera-ui vs. busybox-power, or only recently pardoned worldclock, anyone?).
---

More on-topic:

int_ua, exactly ugly way to achieve what you want for modest-less system, would be to create dummy modest package that mimics real one (just empty), which version always higher than CSSU's one. It will stop mp-fre(...) from bitching and uninstalling itself. For calenda, say hi to method used by busybox-power -> binary replacing files via postscript, with layer of safety checks and backuping (as said, only other - and natural for this kind of package - method would be to ship it via CSSU, but <insert copy of paragraph one here>).

/Estel

FWIW, I resorted to uninstalling the Fremantle MP long ago as part of uninstalling File Manager (see also here for a full list, since then revised with some packages put back but not MP).

One obvious adverse effect, other than missing CSSU version as per Pali's post above, is that CSSU Tuner bitches that CSSU isn't installed - but then it launches and works perfectly fine.

Illegal assumptions. the fact is that devels (or rather: mostly YOU) simply claim that it's too much work to even bother about correct packaging and rather bitch about CSSU maintainer not replacing busybox in MP by busybox-power in MP. This didn't and won't happen. Your definition of what CSSU been invented for is bogus and made up, and your "limbo" you claim is just the limbo of devels who refuse to cope with proper packaging. Simple as that.
just more illegal assumptions and made-up nonsense. nobody wants to even install a cssu-extras repo. And if you would bother to read the policy instead of bitching against it and claiming it's too much work despite you got NFC what it's all about and how much work (heck not even which work at all) it involves, well then you'd notice that you're wrong. And your constant trying to use camera-ui as an argument why other stuff should get added same way, while we all are aware that camera-ui been a break of the policy that never should've happened - can't you think of any better way to argue than this?
Or int_ua has a brain actually, and considers that proper packaging of calendar would be exactly as little work as this suggested botch, just that proper packaging had a chance to actually go into CSSU. And heck, a devel who invests lots of time into a FOSS replacement and then starts crying "but I got no time for proper packaging now" - are you serious? Honestly if you consider packaging overhead prohibitively huge compared to effort necessary to develop a decent app, then you're seriously misguided. Ooops I forgot, you're not at all guided by anything, particularly not by any fuzzy idea what this is all about.

But that's not half as funny as is your bashing merlin and jaffa and mohammadag and me for coming up with and enforcing a sound policy, right? Your lack to even notice that busybox-power, when "included to CSSU" in the way you're bullying for, would be exactly as non-removable as is "calenda" now, and thus wouldn't help int_ua at all when same method would get applied to calendar, it talks enough of a story to everybody to make it obvious what's the issue between you and CSSU maintainers.

Again, for everybody's reference and convenience:
http://maemo.org/community/maemo-dev..._closed_blobs/
http://maemo.merlin1991.at/cssu/meetings/2012-05-14.txt

$ man equivs

It's not on Maemo, but I bet you can easily create Maemo meta-packages from any (Debian-based) linux distribution.

I've done this on Ubuntu to get rid of plymouth and other crap.

It would probably be a lot easier to just create the mr-fremantle-community-pr package by hand. Equivs probably has a million dependencies for the most trivial stuff.

But yes, if CSSU some day manages to detach itself from the "seamless" keyword and finally abandons Nokia and lifts off so as to actually achieve some kind of progress, then I will certainly install CSSU.