On Sat, Aug 11, 2012 at 2:48 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: > The problem is that it becomes more and more difficult to > install a system without all sorts of (for me and others) > useless components such as PA. The reason is lots of hard > dependencies that should be optional extensions instead. > When L.P. claims e.g. that Gnome wants 'usability' and > 'accessibility', therefore it needs and audio stack and > since the best one for desktop use is PA (no discussion) > it pulls in PA, that does make sense. But when it becomes > impossible (using binary packages) to install Gnome without > PA (while accepting the consequences) that just amounts to > *very bad design*. Because technically there is *no reason* > why things should be that way. If Gnome doesn't find the > PA components it needs for certain non-essential funcions, > it should just go on without them. > > The same goes for consolekit, polkit and whatever other > kids the family has grown meanwhile. They do not provide > essential functionality, rather they interfere with the > normal way to contoll access etc., so they must remain > optional. For better or worse, the reality is that there are hard dependencies on things you don't like. It seems that upstream is unwilling to change that. Rather than just complain about it (which will not change anything), why don't you try to find out what upstream would be willing to do to serve your usecase? I know for instance that pulseaudio should be able to disable itself if it finds jackd running (as PA acknowledges that it does not serve the same usecases as jack). Maybe that is not exactly what you need, but perhaps you could request some similar functionality. If you do it in a nice and constructive way based on technical arguments, I'm sure it would be merged. > Now udev has been merged with systemd, and one can wonder > why. According to the authors, it is 'because they share > some common code'. A rather weak argument, that would be > true for almost any two subsystems you can imagine. This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated. It is not the case that systemd swallows anything it shares code with, in fact some stuff is being pushed into util-linux away from systemd. > Udev is perfectly usable and useful on its own, it should > never be merged with something else that should remain > optional. But maybe that's what behind it - in the long > term systemd is supposed not be optional. So what will > be merged in next ? The kits ? Dbus ? Filesystems ? > Networking ? It will end up to be one giant 'system' blob, > take it or leave it, as we know from other platforms, with > no choice at all for the user. I think there is no interest (upstream) in trying to make systemd optional forever, so this is a concern you are probably right about. However, the suggestions of what might be merged show that you are either joking or don't know these projects well. At some point parts of dbus will move into the kernel (so that is something to troll about I guess). -t
