Re: [PATCH] xserver-xorg: remove broken RREPLACES

[Mark Hatle <mark.hatle@windriver.com>]

On 9/14/12 5:16 PM, Phil Blundell wrote:
> On Fri, 2012-09-14 at 17:13 -0500, Mark Hatle wrote:
>> Coming from the RPM world, that behavior is entirely unexpected.  There is no
>> way (by design) for an RPM package to be tagged as being allowed to replace
>> files of another package.
>
> How would rpm conventionally deal with the situation at hand here (a
> file which was previously in xserver-xorg and is now in
> xserver-xorg-module-exa)?

You would have one or more packages dedicate to that or a set of files.. and 
only one of them could be installed at a given time (using conflicts).

Alternatively, if the file is a configuration file, the file is tagged as a 
such.  (But I'm not completely sure even that would work.)

The case I'm most familiar with in proprietary OpenGL drivers. (In an RPM based 
distro...)  By default it used to be that the mesa-libs package would include 
all of the mesa libraries including libGL, and libGLU.  When the proprietary 
versions of those files came around, it was necessary to split off the libGL and 
libGLU into specific packages.. so now you had: mesa-libs, mesa-libGL, and 
mesa-libGLU.  The proprietary stuff provided it's own libGL/libGLU and contained 
a replaces (or conflict) on the libGL/libGLU from mesa.  [besides w/o the 
conflict, the user would get an install error that two files conflicted between 
the packages]

Looking at the item in context:

(meta/recipes-graphics/xserver-xorg/xserver-xorg.inc)

PACKAGES =+ "... \
              ${PN}-module-exa \
	     ..."

RREPLACES_${PN}-module-exa = "${PN}"

FILES_${PN}-module-exa = "${libdir}/xorg/modules/libexa.so"

Based on that, I'm not sure what RREPLACES is being used for:

FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards 
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so 
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt 
${datadir}/X11/xorg.conf.d"

Since under the packaging rules, that one file will only exist in the one 
package, and it won't ever exist in both packages.

So Replaces is wrong under either definition from what I can tell.

--Mark

> p.
>