svgalib-dummy again

[Roman Hodek <rnhodek@faui22c.informatik.uni-erlangen.de>]

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 .