[PATCH] xserver-xorg: remove broken RREPLACES

[PATCH] xserver-xorg: remove broken RREPLACES

[Paul Eggleton]

Unfortunately with rpm at least, this results in xserver-xorg-module-exa
being installed in preference to xserver-xorg when constructing the root
filesystem, which is clearly not desirable.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 .../xorg-xserver/xserver-xorg-1.11.2.inc           |    2 +-
 .../recipes-graphics/xorg-xserver/xserver-xorg.inc |    1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
index c71896a..35cb33a 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
@@ -8,4 +8,4 @@ SRC_URI += "file://crosscompile.patch \
 SRC_URI[md5sum] = "8796fff441e5435ee36a72579008af24"
 SRC_URI[sha256sum] = "fa415decf02027ca278b06254ccfbcceba2a83c2741405257ebf749da4a73cf2"
 
-PR = "r7"
+PR = "r8"
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 210abad..3ec38b7 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -66,7 +66,6 @@ PACKAGES =+ "${PN}-security-policy \
 
 RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb xserver-xf86-config"
 RDEPENDS_${PN}-xvfb += "xkeyboard-config"
-RREPLACES_${PN}-module-exa = "${PN}"
 
 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"
 FILES_${PN}-dev += "${libdir}/xorg/modules/*.la ${libdir}/xorg/modules/*/*.la"
-- 
1.7.9.5

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

[Phil Blundell]

On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote:
> Unfortunately with rpm at least, this results in xserver-xorg-module-exa
> being installed in preference to xserver-xorg when constructing the root
> filesystem, which is clearly not desirable.

Surely this is a bug in the rpm packaging backend and ought to be fixed
there.

p.

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

[Mark Hatle]

On 9/14/12 4:50 PM, Phil Blundell wrote:
> On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote:
>> Unfortunately with rpm at least, this results in xserver-xorg-module-exa
>> being installed in preference to xserver-xorg when constructing the root
>> filesystem, which is clearly not desirable.
>
> Surely this is a bug in the rpm packaging backend and ought to be fixed
> there.

If a package "replaces" another, it has priority.  What is the desired behavior 
in this case?

If a package can't be installed at the same time as another package, then it 
"conflicts".

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

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

[Phil Blundell]

On Fri, 2012-09-14 at 16:56 -0500, Mark Hatle wrote:
> On 9/14/12 4:50 PM, Phil Blundell wrote:
> > On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote:
> >> Unfortunately with rpm at least, this results in xserver-xorg-module-exa
> >> being installed in preference to xserver-xorg when constructing the root
> >> filesystem, which is clearly not desirable.
> >
> > Surely this is a bug in the rpm packaging backend and ought to be fixed
> > there.
> 
> If a package "replaces" another, it has priority.  What is the desired behavior 
> in this case?

The conventional behaviour has been that:

- if a package RREPLACES another (without declaring any other
dependencies) then it is allowed to overwrite files in that package
without producing an error.  This is necessary when files move from one
package to another but both should remain installed.

- if a package wishes to entirely replace another one, it should both
RREPLACE and RCONFLICT with the old one in order to force it off.
Generally it would also want to RPROVIDE that package otherwise the
replacement is liable to cause broken dependencies.

p.

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

[Mark Hatle]

On 9/14/12 5:03 PM, Phil Blundell wrote:
> On Fri, 2012-09-14 at 16:56 -0500, Mark Hatle wrote:
>> On 9/14/12 4:50 PM, Phil Blundell wrote:
>>> On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote:
>>>> Unfortunately with rpm at least, this results in xserver-xorg-module-exa
>>>> being installed in preference to xserver-xorg when constructing the root
>>>> filesystem, which is clearly not desirable.
>>>
>>> Surely this is a bug in the rpm packaging backend and ought to be fixed
>>> there.
>>
>> If a package "replaces" another, it has priority.  What is the desired behavior
>> in this case?
>
> The conventional behaviour has been that:
>
> - if a package RREPLACES another (without declaring any other
> dependencies) then it is allowed to overwrite files in that package
> without producing an error.  This is necessary when files move from one
> package to another but both should remain installed.
>
> - if a package wishes to entirely replace another one, it should both
> RREPLACE and RCONFLICT with the old one in order to force it off.
> Generally it would also want to RPROVIDE that package otherwise the
> replacement is liable to cause broken dependencies.

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.

You can either replace a package, or you can conflict with another.  Replace 
automatically creates a conflict (even though most people specify them both.)

In the RPM world, files are verified, and two packages can not write to the same 
file -- unless the md5sum of the file is the same in both packages.  The only 
exception is when a file is tagged as a configuration file or a "ghost".  (Ghost 
means a package owns a file, but doesn't actually provide the file itself.) 
Even that semantic is different.

--Mark

> p.
>

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

[Phil Blundell]

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)?

p.

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

[Mark Hatle]

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.
>

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

[Phil Blundell]

On Fri, 2012-09-14 at 17:28 -0500, Mark Hatle wrote:
> 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.

The point is that it was in older versions of xserver-xorg.  It's indeed
not in the current version, and in fact it can't be since (due to the
way that FILES works) there is no way for a single file to end up in
more than one of the PACKAGES for a given recipe.

In the particular case at hand I think the problem is relatively minor,
since folks who have an old xserver-xorg installed can upgrade by first
installing the new xserver-xorg (which doesn't ship libexa.so) and then
installing xserver-xorg-module-exa.  But, if the new xserver-xorg had
depended on xserver-xorg-module-exa then this wouldn't have worked
without the RREPLACES.

p.

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

[Mark Hatle]

On 9/14/12 5:37 PM, Phil Blundell wrote:
> On Fri, 2012-09-14 at 17:28 -0500, Mark Hatle wrote:
>> 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.
>
> The point is that it was in older versions of xserver-xorg.  It's indeed
> not in the current version, and in fact it can't be since (due to the
> way that FILES works) there is no way for a single file to end up in
> more than one of the PACKAGES for a given recipe.

Ahh, thats easy.. It conflicts or replaces an older version..

RCONFLICTS_... = ${PN} (<${PV})

or something like that.  Once updated to the current version of ${PN} no conflict.

> In the particular case at hand I think the problem is relatively minor,
> since folks who have an old xserver-xorg installed can upgrade by first
> installing the new xserver-xorg (which doesn't ship libexa.so) and then
> installing xserver-xorg-module-exa.  But, if the new xserver-xorg had
> depended on xserver-xorg-module-exa then this wouldn't have worked
> without the RREPLACES.
>
> p.
>
>