Now that svgalib seems orphaned, allow me to come up with this topic
again... But first a brief summary of the history and the problems:
svgalib-dummy is a dummy replacement for svgalib, which doesn't
require any configuration, doesn't spit out messages when initialized
by applications, and last but not least, can be used as a substitute
on architectures where the real svgalib doesn't exist. Unfortunately,
it cannot be easily installed. Though it Conflicts: and Replaces:
svgalib1, dpkg's current dependency mechanism doesn't allow it to be a
substitute for svgalib, because that is a shared lib and so all
dependencies on it are versioned dependencies (coming from the .shlibs
file).
I now see two solution for this problem:
1) dpkg's dependency handling could be extended so that it knows
about versioned Provides:. Then svgalib-dummy could provide
"svgalib1 (>= 1:1.2.10-2)" or something similar, and a dependency
"svgalib1 (>= 1:1.2.10-1") could be satisfied by this.
Not only that this is the most elegant way, it also solves another
potential problem:
The problem with versioned dependencies doesn't only hit
svgalib-dummy, which wants to replace a shared lib, it will also
effectively make replacements of any shlib package impossible...
Just imagine we sometime want to rename a shared lib, or replace
it by another, improved package. This won't be possible without
rebuilding the *depending* packages, because providing a shared
lib isn't possible...
2) A not-so-nice solution would be to change the .shlibs files of
both, svgalib and svgalib-dummy, so that they read
libvga 1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1
libvgagl 1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1
This signals that either package is ok for providing libvga.so.
The drawback is that all packages depending on svgalib must be
rebuilt with an updated version of svgalib to get in this change.
This could be handled by first announcing here that those packages
should be rebuilt, and if no uploads follow in some reasonable
amout of time, I could report bugs against those packages.
So, what method do you prefer? Or do you have better ideas? How hard
would it be to implement versioned Provides: in dpkg? Or are there
other reasons not to implement it? Is solution 2) too kludgy?
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .