(When am I going to start using the right email address? For crying out loud, Thunderbird.)

On 1/21/23 21:11, Jamie Zawinski wrote:
No. There should be exactly one XScreenSaver package. So, so many problems have 
stemmed from this incomplete, broken installations as a result of this 
ridiculous extras-data-extras-gl-extras-extras nonsense. I am decades weary of 
hearing about them.

lol, to be fair, I don't fully understand what is with all of the tons of "extras" packages either. And I've not been around for long enough to know what all the pros and cons are. But I think that's beside the point for this particular situation.

If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: 1. There will be exactly one possible configuration file that ships with the defaults generated at compile time. 2. That file will become the only possible file that can be shipped in that location. 3. Any attempt to install a package which contains a customized version of that file will fail and cause a broken installation/upgrade attempt due to the file conflict. This technically might be able to be worked around by using a postinst script to replace the file, but that is a very hacky solution to a problem apt already has the capability to solve on its own. (Plus this workaround goes against Debian policy.)

If the configuration file is split out into its own separate xscreensaver-config package, and the core package is made to depend on the -config package, then: 1. The configuration file generated at compile time will be installed by default if a user installs xscreensaver themselves. 2. Software that ships a customized version of that file can also provide a configuration package that uses Conflicts/Provides to replace xscreensaver-config. 3. The package containing the customized file can then be installed instead of xscreensaver-config, all dependencies will be satisfied, and everything will work, but in the way that the file customizer intended.

Yes, this comes with the con of having yet *another* package involved, but it has a clear, practical use case. If you have an idea for how else to allow the configuration file to be customized, that doesn't involve the addition of another package, that would be great.

--
Aaron Rainbolt
Lubuntu Developer
https://github.com/ArrayBolt3
https://launchpad.net/~arraybolt3
@arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat

Reply via email to