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

Re: Files which want to be different in different packages



Bill Mitchell writes ("Re: Files which want to be different in different packages"):
> [...]
> I don't see how your porposal [sic]
> [...]
> I don't follow how the system determins what TRT is
> [...]
> 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.

Next time please read messages and understand them before attempting
to comment !

> 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?

No.

> 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.

My proposal in this area is intended to avoid having to ask questions.

> Ian Jackson <iwj10@cus.cam.ac.uk>
> > [...]
> > 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].

If we want to make the system deal well with new sets of complex
requirements it is inevitable that this will result in extra
`features'.

These `features' do not have be visible to the user in the way that
the knobs on a TV set are.

> 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.

You appear to have completely missed the point of my posting.  How can
you interpret a posting which says `here are some problems, here are
how I think they should be solved, and here is how I think the
solutions should be implemented' as a claim that the default solution
we have now is generally applicable ?

I claim that it is a good default, but I do not claim that it is
sufficient as the only possible behaviour.

Ian.


Reply to: