Comment 77 for bug 192310

Revision history for this message
Mikael Nilsson (mini) wrote : Re: [Bug 192310] Re: package openoffice.org-hyphenation-en-us None [modified: /var/lib/dpkg/info/openoffice.org-hyphenation-en-us.list] failed to install/upgrade: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation

ons 2008-03-05 klockan 20:09 +0000 skrev Nemes Ioan Sorin:
> OK Mikael, no problem form me.
>
> But what I said wrong ?? to deserve such a reply =>
>

I really didn't mean to be harsh - my sincere apologies if it came
across that way.

> "
> 2. If you're not prepared to face packaging bugs, please don't use
> Hardy.
> "
> ??

My point is that these bugs should only happen for development releases.
Ordinary users should *never*, *ever* see a bug like this. And I believe
Steve mentioned automatic reports that are there to ensure that this
indeed never happens for released versions of Ubuntu.

> We discuss about something here - we don't kill anyone. If we wrong -
> please tell us in 3 words -> guys the real meaning of those procedures
> are X. Not Y. Over. All peoples understand - we are all mature I supose.
> This must be the way IF someone do something wrong.

Ok, here is the breakdown.

Assumption: A file that exists in two packages that do not Conflicts:
(according to the package metadata) with each other is a packaging bug.

Given the above, the problems reported by dpkg are there to highlight
the fact that there is a packaging bug. The bug gets reported and fixed
before release of Hardy in this case. All is well, and this is what i
happening here - normal procedure.

So, can we question this assumption? Your alternative is to handle file
conflicts at runtime.

Let's assume there is a library, /usr/lib/libquicktime.so.1.0.0.

Let's assume that this library is part of several packages.
libquicktime1 (naturally), mplayer and xine. All have the same version
of the library, and all are installed. What should happen when
libquicktime is updated? All other packages containing this file need to
be updated. Alternatively, if the upgrade is allowed even though the
file is not identical, what happens if you install vlc, with the old
version again? Maybe all programs stop working, maybe the old version
contains a security vulnerability, etc etc.

Maintaining this would be a *complete* nightmare, and severely decrease
the quality of the distribution.

In fact, I would argue that allowing this would be similar to making the
gcc compiler not produce compiler errors, but instead try to guess the
intent of the programmer and silently "fix bugs". The result would of
course be even more bugs and a complete maintenance nightmare.

The same file in two non-conflicting packages is a bug that needs to be
fixed, and a sign of a working packaging system, end of story.

/Mikael

--
<email address hidden>

Plus ça change, plus c'est la même chose