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

Re: Packages should not Conflict on the basis of duplicate functionality

On Mon, 27 Sep 1999, Brian May wrote:

> However, if both packages contain a different implementation of the
> same file (or even worse - a completely different program with the same
> name), then things will break, depending on what order the
> programs are installed in.

This is true, and would need extra heuristics in the packaging
policy/system to cope with this.  All conflicting files could be
given names that wouldn't clash (prefix them with the first letter
of the package name, or whatever), and then diversions/symlinks

> The warning messages produced when a file does conflict have a tendancy
> to scroll of the top of the screen, and unless you are paying attention,
> there is no way (that I know of) to find what files (if any) conflict
> after installing multiple packages. If I submit a bug report
> against package X, how are you, the maintainer to know that
> it is broken, because an important file, eg /usr/bin/z was overwritten
> by packge Y, which does something completely different?

Um, yes, it's a difficult one, but I don't think the problem is
*that* wide-spread.  I agree with the Apache and Roxen example --
I have wanted to do this as a quite straight-forward thing before,
but I think few packages will have big difficulties.

This won't list all diversions/etc., but you can always diff the
output of `dpkg -L' against two packages to see if files conlict.
Or maybe I mean `sort | uniq -d' -- of course this doesn't help
if some people have chosen /usr/X11R6/bin and some /usr/bin/X11,
for instance.  I'm sure a trivial utility could be made to do this.

I suggest you compile a list of these sorts of problems, and set
about trying to fix them in a sane way, if you have time.

Chris <chris@fluff.org>                         ( http://www.fluff.org/chris )

Reply to: