(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