On 12/19/2011 11:27 AM, Klaus Kaempf wrote:
* Michael Andres
[Dec 13. 2011 09:25]: See https://bugzilla.novell.com/show_bug.cgi?id=736100
The point is that suse patches indeed conflict with packages shipped by another vendor.
So we need to make the patch dependency information richer to cover such situations.
Patches could get a 'vendor' string and only apply to packages with a matching vendor.
Then one has three possibilities
1. All packages referenced by the patch have the same vendor as the patch (normal situation) -> patch is valid and should be considered
2. No package referenced by the patch has the same vendor as the patch (all packages from different vendor) -> patch is invalid and must not be considered
3. Some packages referenced by the patch have the same vendor as the patch and some packages don't (vendor mix) -> user must decide
I prefer the solution of vendoring the patch and keep things simple making the patch simply "Not relevant" if any of the affected packages is from a different vendor than the patch. You can't assume the patch will behave correctly (in terms of fixing an issue) if one of the components was replaced. Now, I would be careful in talking about vendor here. For patch vendor I mean adding an attribute vendor to the package list of a patch. The patch itself should be allowed to have a different vendor, in case a 3rd party is assembling patches (eg. SLMS). - patch name: foo vendor: My Company Inc. pkgs: vendor: SUSE pkglist - foo >= 1.1 - foo-devel => 1.1 -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org To contact the owner, e-mail: zypp-devel+owner@opensuse.org