Re: Bug#1187: Various `vi' versions trample on each other.
Bill Mitchell writes ("Re: Bug#1187: Various `vi' versions trample on each other."):
> [...]
> As I understand it, you're asking that the processing be changed so
> that programs would install themselves under package-specific names,
> and would optionally link package-specific binary names to more
> generic names ("vi", "ex", ...) if those names are not in use.
>
> The first vi clone installed, then, would use whatever generic names
> it wanted. vi clones installing later would only use names which they
> wanted and which were still free (perhaps "ex", but not "vi").
>
> You're also asking that package-specific manpage names be used, and
> only linked to generic names if the binary link is done, and that the
> manpage link be put in place of whatever file or link might pre-exist
> it.
I'm suggesting that we do this if we want to be able to support having
several different versions of a program on the system.
> [ObMention of package-granularity vs. file-granularity handling of
> dependencies and conflicts]
OK, I'll bite. What do you think should happen when two packages
contain a file with the same name ?
Currently (dpkg 0.93.64) that from the package installed earlier will
be overwritten by that from the package installed later. The file
will be considered part of the second package, so that it will be
removed iff that package is removed.
This allows files to be transferred between packages without ever
having to remove any of the packages involved.
A few alternatives I can see are:
(a) Treat files of the same name in two different packages as an
installation error (a bit like a conflict - though of course it
couldn't be detected in advance, so dselect wouldn't know about it).
This seems to me to be unhelpful.
(b) As I do at the moment, but only remove the file when the last
package which contained a version of it is removed. This will prevent
one from ever forgetting about base packages. At the moment base
packages can be forgotten about by having other packages take over all
their files. If we do take this approach it will be much harder to
rename base packages. (Note that all of this applies to non-base but
important widely-Depended-on packages, too.)
(c) Allow package maintainers to assign a priority level to each file
in each package (with a sensible default), and do as I do now if the
new package's priority for the file is higher or the same as that
installed, but ignore the new version if it is lower. This seems to
me to be overcomplicated and not very elegant.
dpkg already supports something that's better than `file-granularity
handling of dependencies', whatever that means. Virtual package names
do not need to be names in the filesystem, and because they must be
declared in the package control files (and thus in the Packages file)
they can be used by dselect.
Ian.
Reply to: