On Tue, Sep 30, 2003 at 03:04:36AM +0200, Michel Dänzer wrote:
> > No, that's not enough. They'll still provide libGL.so.1. libGLU has
> > nothing to do with it.
>
> It's all about it, the conflict stems from it, remember? :) Anyway, I
> don't have time to explain this further, take the advice or leave it.
Look, it's really simple. I'll break it down.
1) xlibmesa3-gl provides the file /usr/X11R6/lib/libGL.so.1
2) xlibmesa3-gl-dev provides the file /usr/X11R6/lib/libGL.so
3) libutahglx1 provides the file /usr/X11R6/lib/libGL.so.1
4) libutahglx-dev provides the file /usr/X11R6/lib/libGL.so
5) packages that provide the same file cannot be simultaneously installed
without Replaces relationships involved, the --force-overwrite flag
being given to dpkg, or dpkg defaulting to force overwrites[1]; dpkg
will fail when attempting to unpack a package that supplies a file
already owned by another package already installed on the system
6) due to 5), packages that provide the same file should Conflict with and
Replace each other
7) libgl1 is a virtual package Provided by xlibmesa3-gl
8) libgl-dev is a virtual package Provided by xlibmesa3-gl-dev
9) any package Providing a virtual package is treated the same as a
package having that name for the purpose of Conflict and Replaces
relationships
10) xlibmesa3-gl's C/R with libgl1 and xlibmesa3-gl-dev's C/R with
libgl-dev is sufficient to avoid problems with
overlapping packages as long as libutahglx1 Provides libgl1 and
libutahglx-dev Provides libgl-dev
11) If libutahglx1 stops Providing libgl1 and xlibmesa3-gl C/Rs
only with libgl1, the package system will let a user attempt to
install them both simultaneously, which will fail because they both
attempt to claim ownership of the same file on the system
(/usr/X11R6/lib/libGL.so.1).
12) If libutahglx-dev stops Providing libgl-dev and xlibmesa3-gl-dev
C/Rs only with libgl-dev, the package system will let a user attempt
to install them both simultaneously, which will fail because they
both attempt to claim ownership of the same file on the system
(/usr/X11R6/lib/libGL.so).
13) Therefore, having xlibmesa3-gl C/R libgl1 *and* libutahglx1 and
xlibmesa3-gl-dev C/R libgl-dev *and* libutahglx-dev will prevent
problems in the event the hypotheticals in 11) and 12) come to pass.
What part of the above is incorrect? What does libGLU have to do with
anything?
Er, well, actually, now that I look at it, items 3) and 4) are wrong.
The Utah GLX packages put their stuff in /usr/lib, but the xlibmesa
packages put their stuff in /usr/X11R6/lib. I still think it is wise to
have the Conflicts there, though, as having both packages installed
subjects the user to the tender mercies of library search path order
(both at compile time and run time). Plus, someday the X libraries will
move to /usr/lib.
Anything to add to the above?
[1] This is what we used to make dpkg do right before a release in the
old days.
--
G. Branden Robinson | No math genius, eh? Then perhaps
Debian GNU/Linux | you could explain to me where you
branden@debian.org | got these... PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley
Attachment:
signature.asc
Description: Digital signature