I thought libpulse0 did nothing without the rest of PA.  What do you need it for?

I decided to see what Apt wants to do with 'install openoffice.org' vs. 'openoffice.org --no-install-recommends'. The latter left out a few packages, but still wanted to include the full PulseAudio system.

That's interesting. I installed openoffice.org a while ago with Synaptic. At first it wanted to pull in all kinds of pulse stuff, but after unchecking the "Consider recommended packages as dependencies" box in Synaptics' Settings>Preferences OO installed fine without it. Pulseaudio now appears in the "missing recommended packages" list.

Pulseaudio doesn't appear directly in OO.o's dependencies/recommends but looking around a bit it might be openjdk-6-jre which wants to pull pulseaudio in, or maybe indirectly some gstreamer thing. I have got to have libpulse0, but no other pulse stuff on my system.

pvsage wrote:

Another reason to move away from Ubuntu is its metapackages are getting loaded with things that a lot of don't want in a lightweight OS, like Gnome dependencies, PulseAudio, etc, yada and so forth, even if the dependencies aren't required for the package's core applications to run properly.  The openoffice metapackage starting with Jaunty is a great example, as it pulls in the entire PulseAudio package.

Isn't some of this because Ubuntu's (and Debian's) default behaviour is now to regard recommendations as dependencies? It is quite possible to install openoffice, for example, without pulse audio if you want.

That said,  I'm curious to know if #! on Debian will still have to use consolekit, policykit or any other "kits" - I'm not sure if that stuff helps with permission problems, or causes them... :rolleyes:

the bigger problem for me is that ubuntu repos tend to assume you should have all the default ubuntu stuff, for example the amount of stuff having metacity as a dependency, rather than just a window manager.

Another reason to move away from Ubuntu is its metapackages are getting loaded with things that a lot of don't want in a lightweight OS, like Gnome dependencies, PulseAudio, etc, yada and so forth, even if the dependencies aren't required for the package's core applications to run properly.  The openoffice metapackage starting with Jaunty is a great example, as it pulls in the entire PulseAudio package.

Isn't some of this because Ubuntu's (and Debian's) default behaviour is now to regard recommendations as dependencies? It is quite possible to install openoffice, for example, without pulse audio if you want.

That said,  I'm curious to know if #! on Debian will still have to use consolekit, policykit or any other "kits" - I'm not sure if that stuff helps with permission problems, or causes them... :rolleyes:

fox wrote:

I don't understand why so many people on this forum seem to be against Ubuntu as a base.  CrunchBang 9.04 used Ubuntu as a base and is a very stable, very fast and lean distro.  I don't think it brought in a whole lot of extra dependencies because it worked from a base install of Ubuntu.  Don't get me wrong, I like Debian as well, but I think Ubuntu is trying to be more innovative with things like fast start (and netbook remixes, although they aren't relevant here).  I hope some of that innovation (especially fast start) will find its way into the new Debian-based CrunchBang.

The reason I gave up on Ubuntu last year is that it's too much of a "compromise" distro. I understand this is a big part of Ubuntu's success, but it just doesn't work for me. Basically, their 6-month cycle is a compromise between stability and freshness. Personally, I would rather use a distro that is either incredibly stable or incredibly fresh. Ubuntu always seems to get really "stale" a few months into its release, but without the benefits of a distro with bug-free reliability as its goal. Plus I have real problems with their "release every 6 months, even if it's broken, and by the way, a fresh install is better than an upgrade" philosophy.

On my work computers, I use CentOS and Debian Stable, with a dual boot into Arch for the rare occasions I need the latest version of OpenOffice or whatever. If you've only ever used Ubuntu, a truly polished and stable distro with many years of support can be a real revelation.

On my home computer, I'm still using #! 9.04, because I just love it so much. :) But I am looking forward to replacing it with Statler when the time comes.

Also:

http://crunchbanglinux.org/forums/topic … uggestion/

What was it that drove #! away from Ubuntu? Necessity, or just to please the distro hopping kid within us? ;) ;)

ZAP wrote:

johnraff wrote:

That's kind-of what I was worrying about - how the "quantum jumps" would be handled..

I wondered about that also when I heard that #! Statler would be based on Squeeze instead of Sid. What's the rationale behind that? When Testing breaks it tends to break for a while, afaik, whereas Unstable gets patched pretty quickly.

Statler is not rolling, and there will be no quantum jumps. It is based on Squeeze, which is very stable and will become even more so later this year when its status switches from Testing to Stable.

If you want a rolling, Sid-based Statler, come join the discussion here: http://crunchbanglinux.org/forums/topic … onversion/ It should be easy enough for advanced users who want to give it a try, but I understand why it is not a "sane default" for all users. :)

Makes sense. Hopefully Squeeze will become Stable soon so that Statler can be released without that still being a work-in-progress. I find that releases tend to get more unstable as they reach the finish line and the devs try to get those last few troublesome things included (although the Debian release process helps avoid this).

johnraff wrote:

That's kind-of what I was worrying about - how the "quantum jumps" would be handled..

I wondered about that also when I heard that #! Statler would be based on Squeeze instead of Sid. What's the rationale behind that? When Testing breaks it tends to break for a while, afaik, whereas Unstable gets patched pretty quickly.

Statler is not rolling, and there will be no quantum jumps. It is based on Squeeze, which is very stable and will become even more so later this year when its status switches from Testing to Stable.

If you want a rolling, Sid-based Statler, come join the discussion here: http://crunchbanglinux.org/forums/topic … onversion/ It should be easy enough for advanced users who want to give it a try, but I understand why it is not a "sane default" for all users. :)

alon_h wrote:

A system based on testing will, IMHO, become diverged from release to releas, as it's not ment to be followed as a 'rolling release', especially not soon after a release. It will work, perhaps even well, but will need constant maintenance... Just like Ubuntu, a clear upgrade path is only planned and implemented when a release is due and the developers know what they're upgrading from/to.

That's kind-of what I was worrying about - how the "quantum jumps" would be handled..

I wondered about that also when I heard that #! Statler would be based on Squeeze instead of Sid. What's the rationale behind that? When Testing breaks it tends to break for a while, afaik, whereas Unstable gets patched pretty quickly.

A system based on testing will, IMHO, become diverged from release to releas, as it's not ment to be followed as a 'rolling release', especially not soon after a release. It will work, perhaps even well, but will need constant maintenance... Just like Ubuntu, a clear upgrade path is only planned and implemented when a release is due and the developers know what they're upgrading from/to.

That's kind-of what I was worrying about - how the "quantum jumps" would be handled: for example, the startup files changed from Jaunty to Karmic (or any other of the changes on that page, for that matter). That kind of stuff can't be done just by updating a package to a new version. Would Crunchbang Central have to handle it?

Me too, though a lot of people seem to like pcmanfm.

jockey worked perfectly in finding the right nvidia driver for my card, after following manual instructions had failed. I hope Debian can do something similar...