children, behave.

first, cssu-extras would only provide packages dependant on features introduced by cssu. Take cuteTube as an example of what to do, it just looks at version and enables features if its installed. That way it remains compatible with stock 1.3, as was always the intention. Only "extras" development worth looking at IMO is regarding building for thumb in addition to basic armel and i386. Currently only a few extras sitting in the thumb repo or forum pages exist.

mp... package is useful for updates, sort of one package to rule them all (or update them). it ensures all packages are kept in sync and it reduces fragmentation of having multitude of versions of one package installed on different devices. this is fixable to an extent with >=package-version.x.y in each dependency.

in the long run it could be stripped down to focus on core system and drivers etc, freeing file manager, modest etc to be removed from it completely or using a virtual dependancy fullfilled by the package of your choice using "provides". Hardware wise, I've already suggested using virtuals over in Neo900 porting thread to allow for device specific packages. freeing filemanager, modest etc is both a blessing and a curse. you can update them independently for quicker fixes but could then end up with problems with packages not updating to bring in fixes for changes introduced in core packages.

whatever happens, your going to need to maintain an upgrade route from stock. this could be a mess of pre/post install scripts to protect packages from accidental removal.

I'll love this feature...

just because it is not possible to call dpkg or apt process from pre/post scripts.

Wrong/lack of logic. CSSU, once, required worldclock replacement to strip above-stock features, then failed to include it. Now, due to public demand, worldclock got included *without* features striping, despite your "didn't and won't happen" in the past. CSSU package inclusion "policy" just doesn't exist, that why I'm putting it into quotes. It depends on random factors, like developer's IRC availability (sic!) and so goes on.
---

To the point - CSSU was and is considered as way to install core system packages (bugfix/actualization), that can't be installed properly via other means. I haven't made it, read CSSU wiki landing page

Upstream busybox version is prime example of such package - outside CSSU, it need to be "installed" by scripts doing binary file replacement. It's more prime candidate for CSSU, than half of CSSU's packages, peripod. Lack of it in CSSU is more about politic and "some" people's dislike for busybox as a whole (and preference to install and promote bash on N900, despite it creates syntax-compatibility mess and unnecessary fragments).

Funny "requirement" for busybox maintainer to create a *fork* of upstream version stripped of features non-present in vanilla busybox (!) was made at the same time, when worldlock replacement's maintainer was asked about the same thing. I don't know why anyone came with such stupid idea, but it got scrapped for worldclock - additiona features are there, in CSSU version - and same should happen for busybox-power, *if* CSSU would have any consistent package inclusions policy.

Now, pretending that it *does* have one, is plain lie. Simply browsing through things included in CSSU proves that. There is *no* single meritocratic logic in it, just some random like/dislike/available or not on IRC/politic causes.

At least, in my opinion - everyone can made their own, if ever go through "pain" of trying to plot any logic CSSU maintainers might have, based on packages included (in real life). Statement on wiki or anywhere else are one thing, reality looks completely different. I strongly suggest checking it privately, and getting own opinion.

I'll end it here, as it's not what whole topic is about.

/Estel

ability to click on links and actually read and understand what shows up when doing that click - a blessing not everybody seems to enjoy.
Just so much: particularly for busybox there's not "the one upstream version" since busybox gets configured for the destination platform. You're trying to force a new configuration into maemo which differs massively from the config chosen by original distro maintainers. I don't see any rationale that can explain why this would be a sane thing to do.

All of that was an interesting info. Excluding some offensive/ad hominem arguments. Please don't argue, these are the exact sciences we are talking about, not some humanities (no offense). There are a lot of problems, but blaming anyone isn't a solution. And besides, everyone here has the same goal: to improve something.

I've changed the title in an attempt to reflect the subject more carefully. Now I'll try to gather arguments in a short list...

Problem: remove a package that mp- is dependent on.

• Remove mp- too.
  - could break updates and some debugging
  + but possible to still have a working system. At least for now.
• Make mp- dependent on the package in question OR some other empty package:
  - HAM doesn't support "OR" (needs confirmation)
  • patch HAM
  - which of the alternatives should get auto-installed?
  • Isn't it the first one in the list?
  ? possibly needed in future
• Move some dependencies of mp- to the postinst script
  - not possible to call dpkg or apt process from pre/post scripts
• Make an empty package with the same name and some huge version number:
  + ... kind of.
  + man equivs
• using "provides"
  ?

What did I miss? Can you please make something similar for busybox?

busybox already got sorted. everybody incl the package maintainer is content with the solution, just one guy can't stop bitching

When I installed OpenOffice in Easy Debian, it pulled a LOT of other packages. I later removed many of them to save space and apt did not object or tried to autoremove openoffice. How does that work? Clearly openoffice does not depend on those packages yet installing openoffice installs them as well. Could we use a similar mechanism for mp-fremantle?

that was so-called "suggested" packages. i afraid that HAM doesn't know about this thingy.