[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Files which want to be different in different packages

Raul Miller <rdm@tad.micro.umn.edu> said

> Hypothetically, given packages elvis, nvi, vim, vi++ and vip which all
> provide the executable /usr/bin/vi, if only one is installed this
> executable would be /usr/bin/vi.  However, if all five were installed
> the executables would be /usr/bin/vi.{elvis,nvi,vim,vi++,vip} and
> /usr/bin/vi would be a soft link pointing to whichever "got there
> first".

I'm not sure what nvi, vim, vi++, vip, stevie, vile, or other vi clones
(some of these are not [yet?] debian packages) might do.  What elvis
currently does is to install its executable in /usr/bin/elvis.  Then, 
in its postinst, it looks at vi, ex, view, and input in /usr/bin, and at
similarly named files in /usr/man/man1.  If  the postinst finds that any
of these exist and is not a symlink to elvis, it outputs a message which
tries to explain the situation and exits indicating success.  Otherwise,
the postinst links all these to elvis.  The other vi clones might do
something similar, or might not.

If what I've suggested were implemented, I'd expect to put these links
directly into the elvis package.  the package admin tool then would
install these links if they're not present or if they "collide" with
a previous link "owned-by" elvis (the mechanism for determining 
"ownership" hasn't been discussed here -- call it TBD for now).  If 
a link from the package collides with a file or in-place link not 
owned by elvis, the package admin tool would prompt, asking if I wanted 
to leave the current file or link in place and not install the link 
from the package, replace the existing file or link with the link from 
the package, or abort installation of the package.

Bear in mind that I'm proposing this as consistent processing for all
files in all packages -- not as a special case.

Ian's suggestion, at least as I understand it, and viewed in the
context of my description above, might add additional options
about what to do with the in-place file or link and the colliding
file or link in the package.

Reply to: