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 used. > 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 <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )
