I've missed the start of this discussion, but I'm the maintainer of svgalib-dummy, and the issue of dependencies came up already several times...
> Are there other people that would like the dependancy change > > - Depends: svgalib1 (>= 1:1.2.10-2) > + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy This would indeed be a fix for the dependency stuff, but only for the package that adds this |svgadummy. To fix the svgalib/svgalib-dummy problems with way, every depending packages would have to be changed similarily. svgalib-dummy indeed has a "Provides: svgalib", but unfortunately this doesn't have any effect... Since svgalib is a shared lib, all packages depending on it depend on >= some version. And such versioned dependencies can't be fulfilled by a Provides: :-(( This is not only a problem for svgalib-dummy (which can't really be used as a proper substitute for svgalib due to this), but it has also other implications: We'll never be able to replace or rename a shared library package! Currently, packages that are to replace an older one (renaming is a special case of this) have fields Replaces: and Provides:. But this works only as long as no other package has a *versioned* dependency on the package to be replaced. I see this as a kind of shortcoming of the dependency checking: It should be allowed to have versioned Provides: fields also (e.g.: "Provides: svgalib1 (1:1.2.10-2)". With that, you also give the version of the other package whose functionality is provided, and some dependency (e.g. "Depends: svgalib1 (>= 1:1.2.10-1)") can be fulfilled. I don't know how difficult this would be to implement in dpkg, but it would be a win not only for svgalib-dummy, but also for the future, in case we'll need to replace a shlib package sometimes... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .