Re: Bug#1712: Tex has no version number texbin does
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.
Reply to: