Re: Files which want to be different in different packages
Ian Jackson <iwj10@cus.cam.ac.uk> said:
> * In the case of vi it is clear that each package should contain
> /usr/bin/elvis or whatever, and that /usr/bin/vi should be a symlink
> of some kind. The requirement to allow the system administrator
> control shows that we need /usr/bin/vi to be a link to /etc/vi (just
> like /etc/X11/X), or that we must require the system administrator to
> use /usr/local/bin/vi and put that first in the PATH and tell the
> sysadmin that we're doing so.
X11 is a large system of packages, either with a single maintainer
for all packages or with the various packages involved with these
sysmlinks maintained by closely cooperatiing maintainers. I
don't have X11 installed at present, but I seem to recall that
the symlink is initially set up by a utility script which is
installed by one of the numerous X11 packages (perhaps xbase?),
and that postinst processing by other packages (the servers?)
asks about the sysadmin's desires regarding reconfiguring of
the symlink in a consistent manner from package to package.
The several vi clones are separate packages maintained by widely
separated maintainers who don't talk to one another. Close
coordination is difficult. Enforcement of coordination
is nonexistent. Guarding against a maintainer who is not
in-the-know regarding special vi-clone package conventions
putting together a vi clone package which doesn't follow these
special conventions is not done -- especially in the case of
packages which might be distributed thru back-channels and
never see the central distribution, and which may clobber
any such special-convention arrangements when installed.
Also, I don't see how /usr/local gets involved in this, unless
it's to say that _only_ central_distribution packages should
install files into /usr/bin (and other directories not named).
Are we saying that files from central_distribution packages
might be installed in the /usr/local tree?
I had said:
+ Need #1 -- Support all the systems mentioned in the presumptions
+ above, and try to do a good job of it.
+
+ Need #2 -- Tread lightly on files installed by the operator
+
+ Need #3 - Minimize the need for coordination between package
+ maintainers
+
+ Need #4 - Support alternate versions of program and
+ non-program files
+
+ Need #5 - Dependency and package admin
I think I was beginning to ramble by the time I reached #5, and
#2 involves policy issues still being discussed, but #3 hasn't
been questioned. I'm really not clear if what Ian proposes would
require more coordination between maintainers in order to work well,
but it sounds to me as if it might. If it would require more
coordination between maintainers in order to work well, it seems
to me that it'd be unlikely to work well.
Ian went on to say:
> This leads me to think that we have two specific requirements/features
> which aren't currently supported/available: [...]
Several paragraphs of fairly complex specification of requirements
followed. It seems to me that it would be easier, less complex, and
more general to install the collision-point files silently if there's
no collision, and prompt about what to do about file collisions when
files to be installed from packages collide with already-installed files.
This could (should) be done as default handling of all files which would
be installed from packages -- not as a special case. The major special
case which would need to be handled is installation of a file from a
package which collides with a file previously installed by that same
package. This would need to be handled as a non-collision case or as
a package conffile.
Regarding the prompting for what to do about collision files, I'd
just been thinking in terms of options to overwrite, to not install
the collision file from the package, and to abort package installation.
Perhaps additional options to move the existing collision item
someplace else, to install the package file someplace other than
specified by the package, to install, remove, or re-write symlinks,
etc. should be options as well, but I don't have a clear and specific
picture of precisely what those other options would be. I think it'd
probably be sufficient to initially implement options just the first set
of simple and well-defined options.
Reply to: