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
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 <chris@fluff.org> ( http://www.fluff.org/chris )
Reply to: