I'm getting more and more sick (this stretches over more than one year already) about the way some Debian-maintainers handle this matter.
I'm strictly adhering to aptitude as this seems, especially in the testing-environment, to me the best way to avoid troubles.
Well, I believe my behaviour in this is right, I never encountered in the past 3 years major troubles with updated packages.
BUT there are appearing more and more packages, that SHOULD be updated but where I see absolutely no necessity to have them installed at all!
Only 3 examples hereof:
- poster, to print really big posters (absolutely no use)
- libxss1 for oh so nice screensavers (blank-screen is more efficient)
- libthai for that language (I like the food and the people, no use for their characters or whatsoever).
Well, starting deselecting anyONE (yes, one) of these - and the not mentioned almost 50 others - leads in aptitude to an increasingly bigger red screen: unfullfilled dependency in A, B, C, D, aso. I followed several times via "~b" what had to be removed to keep the needed dependencies in life. Well, everytime I almost ended up just at the brink of having nothing anymore besides the kernel (I always compile him myself and so he stays in a protected area, to my big pleasure) and a miserable rump of a Linux-system.
Don't laugh, just try it yourselves with whatever program you deem to be not necessary on your system. 6 or 7 out of 10 times you'll experience the same misbehaviour as I did and do.
Couldn't we give a non-negligible couple of the maintainers - not to mention the big leaders - a tremenduous kick in their a***s just to keep their packages really in good order in stead of fighting with all their energy what they think not to be in the "true spirit of Debian"?
Debian rules.... but not long anymore with politicians iso real enthousiasts dictating the way to go!

I think what you just said is that you don't like the way Debian does package management. If that's correct, I'm left wondering why you put up with for over a year. There are lots of other choices.

The modern package management system is a huge convenience but I suppose it could be a downside if you start customizing too much.

One extreme in Slackware. They seem to pride themselves in not managing dependencies--perhaps some of their reasons relate to your experience. Another extreme is Gentoo. Everything is compiled so now you have more variables to deal with.

Personally, I think the Debian system is one of the best. If it's causing you grief, then it might be time to switch distros.

This type of problem doesn't happen with apt-get.

It doesn't happen with Aptitude either if you know what you're doing.

Neither apt-get nor aptitude installs anything unless you chose to install it. Most of the time, newbies will install anything, with no clue of whether they want it or not. If you install metapackages (kde, gnome, etc) the problem can explode ... again, no matter what package manager you use.

If you don't want packages, use # aptitude remove to get rid of them. Assuming they were installed as part of a metapackage, you may have some surprises in store. Using aptitude cleans up EVERYTHING. Using apt-get leaves most of the clutter there.

Try adding these lines to your /etc/apt/apt.conf file: You may not have an /etc/apt/apt.conf file yet; that's ok too. Create one and put those lines into it. It keeps aptitude and newer versions of apt-get from automatically installing recommended packages to your system. In my experience, it cuts down on clutter.

Aptitude is like your mother: "I cleaned your room" means "I threw away that 40 year Spider Man comic you found at a garage sale."

Not modern versions. It nags you that you should remove un-referenced depencendies, and tells you how to auto-remove the, bu lets you decide!!

I'm an Aptitude fan, but I still think this way of putting it is brilliant. For me it was coming home from camp one summer, and all my baseball cards (Hank Aaron, Roberto Clemente, Bob Gibson...) were "cleaned up".

Don't be offended please, but I'm sorry to say, that you should have read better and also the whole of my message, not picking out what you think I've said.
Firstly, I use Debian-testing already for 3! years and that very much to my liking. The same goes for aptitude, now even promoted to the most preferred package-manager by Debian. I stated that clearly in my message!

My one and only grief is the sometimes absolutely un-understandable way, superfluous and irrelevant dependencies are forced upon the user. The user, yes; I doubt, but who am I, if a developer or maintainer wouldn't need much more and also other programs to do what he is striving at.
Just give me ONE good reason for each of the 3 examples in my original message, why I MUST have them installed! There are 3 flavours in package-management: depends, recommends and suggests. OKay, although I personally see no tremenduous difference in the meaning of suggests and recommends for the user, but leave that.
Well, after you have come up with the reasons I asked for, what I very much doubt, are you still convinced, that downgrading these (and a lot of other) dependencies to recommends/suggests would end up in a downside for the whole system? Be honest please.

That was one of the reasons I switched from SuSE to Debian more than 3 years ago and not to Slackware. The best of 3 worlds I thought and still think.

Have I made by now clear, what I am getting more and more sick of in Debian but in spite of that not having the slightest intention to make a switch to another distro?

You are completely right with your statement, whether it is "newbies" or "metapackages".
But when the newbie grows up and at a certain moment discovers, what metapackages do, he wants to adjust his system according to his whishes and needs. First of all, the metapackages themselves are removed (quite a tedious job I know from experience from 2.5 years ago) and then he starts to clean up the, in his environment and usage, superfluous packages. Till he is struck by some ridiculous dependencies, the benefit whereof he can not understand at all. But he also has no way whatsoever to navigate around them. And that's, what I wanted to state.

Any more helpfull comments or hints from your side available?

Yes, aptitude does that and I won't ever use another another package-manger to keep my system up-to-date just because of that!
The misery lies with some of the maintainers, who state a fixed dependency in their package, that sometimes is absolutely crazy. See my 3 examples out of a considerable lot. Aptitude only follows this - how should it know better - and therefore is not to blame at all. In the contrary: it has to be praised for the fact, that it prevents the user from deleting necessary packages.

How should they have done for libthai for example?
pango-nothai and pango-withthai
?

Indeed, I don't have this file. BUT neither with apt_0.7.6_i386.deb nor with aptitude_0.4.6.1-1.1_i386.deb such a file is foreseen! These 2 versions were state-of-the-art yesterday, 12/03/2007 in US-dateformat.
I have checked the options in aptitude itself: they were! and are still at "recommends=no".
Above on that, aptitude insists on "depends" and not "recommends" when I want to start a cleaning-action. All the packages in red signal this significant.

Just, please, look in testing only at my 3 examples - shouldn't take more than a minute - and then give me the reason, why these are dependent and not recommended and so can't be removed.
Your father Odysseus greets you, stay learning.

There may well be good non-obvious reasons for those dependencies to exist. I think there are two ways of finding out: a) by contacting the package maintainer, b) by taking a look in the source code of the package.

libxss1 Reverse Depends:
xprintidle,libxss1
xplanet,libxss1
xbase-clients,libxss1
xautolock,libxss1
x2vnc,libxss1
tleenx2,libxss1
tk8.5,libxss1
timeoutd,libxss1
rsibreak,libxss1
qvwm,libxss1
qingy,libxss1
psi,libxss1
pidgin,libxss1
licq-plugin-qt,libxss1
licq-plugin-kde,libxss1
libxss1-dbg,libxss1 1:1.1.2-1
libxss-dev,libxss1 1:1.1.2-1
kpowersave,libxss1
kdesktop,libxss1
kde-guidance,libxss1
karm,libxss1
imms,libxss1
gtimer,libxss1
gossip,libxss1
gnome-screensaver,libxss1
gnome-control-center,libxss1
beagle,libxss1

libthai0 Reverse Depends:
scim-thai,libthai0 0.1.7
libthai-dev,libthai0 0.1.9-1
libpango1.0-0,libthai0 0.1.7
gtk-im-libthai,libthai0 0.1.7

poster Reverse Depends:
taskjuggler,poster
kdeprint,poster

What happens if you take pango original and compile it with thai support and then remove the shared library of thai from /usr/lib and try to run a pango app.
If pango does'nt manually open the dynamic libraries, it has no way to check thai avalability before using it.

So I guess most of the libs are either required or not. ??
If not, then complete support is removed.

Just read please what is stated at www.pango.org:

Well, I searched for all the other languages, NONE of them is installed one way or another in or on my system according to aptitude (/hebrew as search-string, aso).
Shouldn't they also be required according to "dynamically"?
No, dear friend, the maintainer of pango, in this particular example (and a lot of others in other, not even mentioned, applications) made a big glitch by not thinking of what is really necessary and required in the real world. Just what his environment is, nothing more.

Phiebie, I think you're missing the point. People here is focusing on how software is written, even if pango example was unfortunate. The package maintainer (_not_ the developer) has no choice but... choose what to include in the configuration and what not to, whenever software (e.g. KDE), for example, needs to be linked against another (optional or recommended) piece of code. So, what would be the "correct" choice? Include nothing? All? Made many different packages maintaining all the possible combinations? Write software another way? Maybe.

I understand your complaint, and that's why aptitude has features to support recommended packages, but we can not put the blame on package maintainers' shoulders.

I've been a slacker all life long and sometimes I'm tired of rebuilding a package because I added I library I thought I wouldn't use. And unfortunately I haven't seen many programs which check its dependencies at runtime.