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.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
