On Mon, Jan 4, 2010 at 10:34 AM, Luke Imhoff
On Mon, 2010-01-04 at 09:59 -0600, Jon Nelson wrote:
On Mon, Jan 4, 2010 at 9:51 AM, Adrian Schröter
wrote: Am Montag, 4. Januar 2010 16:23:29 schrieb Jon Nelson: ...
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
If you have two packages with same provides name you get an expansion error. Unlike rpm/zypper/yum/apt/... the OBS needs a unique definition to guarantee that a rebuild is reproducable.
The specfile for foo does not have a "Provides: foo". Do rpms have an implicit "Provides: $packagename" ?
So you need either the prefer one of them or remove the other one.
I'm not sure what that means.
Apart from that, bar should be used if it provides foo.
I am using 1.6. Also, the above statement appears to conflict with what Luke said (which is "first found" wins).
I was also wrong about one thing: the "foo" package actually comes from one of the the project configuration's <repository/> <path/> elements. Does that matter? I would have expected the following behavior:
1. parse specfile. 2. one of the build deps is "foo" 3. the current project has "bar" which obsoletes and provides "foo". use that to meet the build dep.
Whether it's an expansion error or it picks first depends on if foo and bar have the same precedence.
If foo and bar are at the same level, so from the same project or both package found under --prefer-pkgs directories, then they conflict and you get an expansion error.
What is "prefer-pkgs" ??
If foo is in the current project (precedence 1), but bar is in a build repository path (precedence 2), then foo wins since the scheduler will pick foo over bar. This is how you can rebuild something like glibc in a project and have everything in the project use that glibc instead of the one from openSUSE:Factory when openSUSE:Factory is a build repository path.
Actually, for me it's the other way around: bar is in the current project (precedence 1), foo is in a build repo path (precedence 2). Packages in the project all have "BuildRequires: foo" and "Requires: foo". However, foo is still being installed instead of bar.
If foo and bar both come from build repository path projects then whichever path entry (in the xml) is first wins.
Ah. *first* wins? Interesting. Good to know. That doesn't help this situation, though. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org