Re: Files which want to be different in different packages
Ian Jackson <iwj10@cus.cam.ac.uk>
>Bill Mitchell writes (reordered by iwj):
> 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.
I did notice the subject change. I guessed, apparently wrongly,
that you had picked up one of several discussion threads which had
spun off of my "Conflict/dependency granularity" message and
changed the subject to be more descriptive of the thread. If
you think my thoughts are unhelpful, feel free to ignore them.
> 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.
And I thought that you were arguing that the processing suggested
was more effective in dealing with the situation than alternatives
being discussed in the parallel thread. Apparently I misperceived.
> > [...] 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).
Elvis, the only vi clone for which I know the details, does use a
symlink. I must have underexplained that. In the above, I was using
"files" as shorthand to mean "files or links". I thought that would
be clear from the context. Apparently, I was wrong. Sorry.
I don't see how your porposal necessarily does less prompting than mine.
Both detect a collision, and ask what to do about it, right?
In any case, I doubt that it matters much whether a package asks one
question, or two, or three. The big jump is between zero questions
for a package and one question for a package. If the package does
ask one question, asking a second isn't that big of a jump.
It's better if the questions are standardized ones and come from the
package admin tool than if they are individualized by package and
come from the postinst. Dealing with routine standardized questions
will be less obtrusive than dealing with individualized ones. I
think both your suggestions and mine seek to accomplish this.
> [...]
> > 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.
Apparently, I was unclear here as well. I meant "collide" in the sense
that the file or link in the package has the same pathname as a file
or link already present on the system. What I was trying to say was
that, in my scheme of things, there would be a special case if the
package installing this file or link was another instance (perhaps
a different version) of the package which installed the file or
link on the filesystem. In that special case, the file or link
involved should be handled either 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.
>
> 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.
I don't follow how the system determins what TRT is, so it can Do it.
Say the installer selects the elvis, vim, and nvi packages in dselect for
installation. All of these are vi clones. How does the system determine
which one the installer wants linked to /usr/bin/vi without asking him?
> [...]
> 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).
> [...]
> > 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'm not convinced of that -- or at least not that the different types
fall into broad enough and definable enough categories to be identified
at package install time and handled specially. It does sound plausable,
though. If clearly definable categories of competition can be
characterized and can be reliably recognized at package install time
(possibly by being declared at package-build time), I agree that special
handling might be appropriate category-by-category. There'd need to
be a good general-case default, and the case where two packages
declared a given pathname to be in different handling categories,
or one declared it and the other did not, would need to be considered
and handled. Sounds compilcated.
> 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.
I (predictably :-) disagree. However, I read through your proposal
quickly, and wasn't comfortable that I fully understood it. I haven't
had time yet to go back through it more slowly. I'll try to do
that tonight.
> 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.
And I'd like to reduce the number of 'features' on the package admin
tool, not increase them. [reference my earlier remarks about too many
adjustments on the back of the TV set which need twiddling].
> 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
I agree with both Ian and Dan here. I think we do tend to
over-engineer, agree that Dan's script is a straightforward
solution to the special-case vi-clone problem, and agree with
Ian that a general solution is needed.
My point of disagreement with Ian here is that I don't think the
general solution we have now (the default behavior in the absence
of any special-case handling) is a good one.
Reply to: