Erick Branderhorst writes ("Bug#1712: Tex has no version number texbin does"): > [...] > > It might be usefull to let the provides packages have the same version > number as the providing package, or if a specific version number is > given in the provides line providing that version number.
The only sensible thing, I think, would be to have providing packages have to specify a version number in their Provides. I deliberately didn't do this, because I didn't think it would be useful. I originally intended virtual packages to work as Bill suggests: Bill Mitchell writes ("Virtual Packages and version numbering"): > Virtual packages were originally proposed, as I recall, to provide > a means for alternative packages which conflict with one another > but seek to provide the same facility to declare that they each > provide that facility so that other packages could declare > dependency on the facility rather than on the packages. [...] (And other similar situations, yes.) In this case, as Bill notes, there is no need for version numbering. > [...] > In practice, virtual packages seem to be actually being used to > provide one or more aliases for one single installing package > providing a facility which is not also provided by a conflicting > package. Eric's suggestion would seem to be useful in this use of > virtual packages. The reason why packages need aliases (apart from the one in your first paragraph above) is either because the concrete package names are part of the internal structure, which may be rearranged by the package maintainer at some point, or because the package names have changed and the old names have to be supported for the benefit of older packages. In the case of `hiding' of internal structure, programs that need a specific version of the actual packages in question are sufficiently closely linked that they can use the concrete package name. In the case of rearrangement, there is no sense in using version numbers. I'm working from the premise that only closely-related packages need to know about each others' version numbers. This seems to me to be fairly accurate. It's true that I could add this feature to dpkg, but the conflict/dependency semantics are quite complicated enough already. Adding new complexity here without a good reason seems to me to be inviting trouble, both in terms of implementation bugs in dpkg and dselect (there is a lot of quite hairy code involved here) and in terms of problems caused by package maintainers misunderstanding things. We need a manual that documents things so that package maintainers don't report things like this as bugs. I'm closing this one. Ian.