> There's actually a good question to ask here. Why, exactly, is xscreensaver > divided up the way that it is in Debian?
Two reasons: 1: Because in 1998, some dude wanted to save a few hundred kilobytes on his machine that didn't have a GPU, and had a hard drive an order of magnitude smaller than the one on my keychain. 2: Because the Debian (and Fedora) maintainers enjoy regularly wasting hours of my and their time on obscure bugs where the solution turns out to be "you installed *half* of the application, and nobody has ever tested it that way". It is trivially easy to fix this bug: they don't even have to re-write their build scripts. The problem can be solved with a one-line change: simply make "xscreensaver" depend upon "xscreensaver-data", "xscreensaver-data-extra", "xscreensaver-gl", "xscreensaver-gl-extra", "xscreensaver-screensaver-bsod" and "xscreensaver-screensaver-webcollage" and whatever else is lying around. Leaving out random pieces of XScreenSaver and hoping that it still works is absolutely, explicitly unsupported by me, the author. That the distro maintainers continue to intentionally insist upon screwing things up this way is absolutely baffling to me. I have been begging them to fix this for literally decades. I can *maybe* see the argument for allowing the hacks to be installed without the XScreenSaver daemon, for the case where some other screen saver framework wanted to run them -- except that none of the other extant frameworks can do that. They used to, but that was years ago. However, if the XScreenSaver daemon is installed, then *all* of XScreenSaver must be installed, or else you get all kinds of weird bugs. That is how it was designed, and that is how it was tested. Trying to install bits and pieces of it and hoping that it still holds together DEMONSTRABLY does not work. -- Jamie Zawinski • jwz.org • dnalounge.com
