Re: Files which want to be different in different packages
Bill Mitchell writes (reordered by iwj):
> I had said:
> + [Need #1 ... Need #5 descriptions deleted]
My message was not a response to yours. I agree with what Richard
Kettlewell has said in response to your messages. I don't think your
comments, insofar as I agree with them, give us any particularly
helpful insights into what ought to be done.
The realisation of the new dpkg has allowed me to see what problems I
think remain, and it was those remaining problems that I was trying to
address in my last message.
> [Presumably in the scheme I describe ...] 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 --
Yes it is. It will happen quite automatically as part of the normal
package development, mailing list and bug reporting process. A
maintainer of a prospective `vi' package will surely realise that
there are other `vi' clones, and in any case the particular special
handling for certain files will be documented in the packaging
guidelines. If they don't then maintainers of other `vi' clones will
probably notice the bug quite quickly, and even if not then my
proposed symlink-management script will.
> 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.
I don't see it as our responsibility to protect against people who
fail to read the documentation or the other materials involved in the
project, produce broken packages, and therefore hose their friends'
systems.
There are much easier and more damaging ways to screw up that we don't
and can't protect against.
> 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?
No. I'm saying that the magic competing package script could offer to
do a bit of work for the sysadmin, by helping them to use /usr/local
to override Debian's standard scheme if it finds that they've been
trying to override it in the wrong way by munging links in /usr/bin.
> 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 (a) doesn't meet our requirements for either of the two kinds of
situations outlined (in the `vi-like' case it fails to produce
automatic reallocation of the symlink, and in any case it fails to use
a symlink at all) and (b) causes unnecessary and probably confusing
prompting during installation (which we should avoid).
> 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.
You mean `installed by a different package' at the end of your 3rd
sentence, I think. If you don't it doesn't make sense. A package
can't `collide' with the files from a copy of itself which is being
unpacked onto the system.
If you do mean that then: no, there is no single sensible default
action. What the sensible default action is depends on what kind of
overwriting is happening. In most cases it will be simply that one
package (usually a base package) is taking over file(s) from another;
in others it will be one of the two kinds of situations I outlined in
my mail, each of which needs to be handled differently - and this must
be done automatically. In other cases it will be some other different
thing, which we should handle as we see fit there and then.
> 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.
No. Imagine the user selects all the non-conflicting packages. They
should not then have to answer obscure (to them) questions about what
to do with /usr/bin/vi. The system should just DTRT.
Raul Miller writes ("Re: Files which want to be different in different packages"):
> Bill, what I think you're saying is, given packages which do not
> "Conflict:", and files within the packages which have the same path,
> we should be able to define a clear and simple mechanism for dpkg to
> use in these cases.
The mechanism that dpkg uses by default is well-defined, though the
documentation is currently only a large comment in the source code. I
think that the current behaviour is a good default (ie, the behaviour
that dpkg ought to have in the absence of special action by the
package maintainer), and it is what most people would expect.
> 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 don't like this scheme. If /usr/bin/vi could be any of them it
would be better for them all to avoid the name and have /usr/bin/vi
just be a link to which one it really is.
> Presumably, we could have some sort of follow on program (or dpkg
> option) which would prompt the sysadmin for what to do when the
> concept of "which got there first" is ambiguous.
The scheme I proposed doesn't suffer from any such ambiguities. The
user never needs to be prompted unless they did something to the file
in question.
I think this is a good rule of thumb: we should in general try much
harder to avoid prompting the user about a particular file (conffile
or otherwise) when they haven't `done anything' to it and are thus
unlikely to know anything about it.
> Ian, I think this follows pretty closely along the lines of what you
> were proposing -- it just dumps more of the work on dpkg. I think
> this would be reasonable, should we agree that the policy this
> implements is reasonable.
Bill's policy is quite different to mine. I'm proposing good
automatic handling of the two types of problem situation that we've
seen so far. I want to avoid prompting behaviour under `normal
circumstances', as much as possible. I definitely don't rule out
further `extensions', ie the ability to make dpkg behave in ways that
we don't think of now, but I think we should consider those additional
requirements when we come across situations that have them.
Bill appears to be proposing some kind of `kill all birds with one
stone' scheme, which I believe will have to be unhelpful by its very
attempt at complete generality (and therefore its heavy reliance on
the user to sort things out, because it doesn't have the information
to do so itself).
Bill Mitchell writes ("Re: Files which want to be different in different packages"):
> If what I've suggested were implemented, I'd expect [ deleted -iwj ]
>
> Bear in mind that I'm proposing this as consistent processing for all
> files in all packages -- not as a special case.
This is fundamentally missing the important fact that there are
different types of competition between different packages for the same
pathname.
I think my proposed handling is strictly better than yours for the
cases I've outlined and those like them. I think that other cases are
likely to be rare, and can in any case be dealt with as they arise.
If you want to discuss any situations that aren't sensibly supported
by the proposals I have made please go ahead: I think we'll find that
they will then require yet another `feature' of some kind.
Daniel Quinlan writes ("Re: Files which want to be different in different packages"):
> No offense intended, but Debian developers seem to be very fond of
> over-engineering simple problems.
>
> I suggest installing a `vi' shell script and manual in the base
> system.
This would be a reaonable solution for this particular problem, but
the issue is I think going to appear quite frequently and it would be
good to have a general solution (both to the `vi-like' and to the
`wrapper' conflict problems).
On the other hand, if it is the sense of the list that `vi-like'
contention should be solved using Daniel Quinlan's admirably
straightforward (but obviously somewhat harder-to-coordinate and less
general) method then that is what we should do.
That would leave the harder problem, `wrapper'-style conflicts, to
solve.
Ian.
Reply to: