Bugzilla – Bug 503276
Different vendors for different repositories
Last modified: 2012-07-02 08:39:18 UTC
Could you please be so kind to change your scripts so different OBS repositories have a different / unique vendor? The reasoning is that the zypp folks claim that "vendor stickiness" should be enough but it doesn't really help if the whole OBS is one single vendor. Personally I would prefer some "Smart" style where I am able to set different priorities for repositories __as well as packages__ but since this wont happen the only solution seems to be to enable different vendors per repository on OBS. E.g. simply use the repo names - home:bitshuffler for my own one or openSUSE:Factory or KDE:KDE4:Communtiy and so on. The reasoning is that I would like to be able to get packages for some application from a certain repository. Now, if I use some other repository for some reason that provides the same package I get switched to the other version without being able to prevent that (since all those repos have the same "vendor") which is, IMHO, simply not acceptable in quite a few settings.
The problem is that this change needs a big announcement, as otherwise people will complain that 'zypper up' suddenly stopped to update their packages.
Agreed, that might be quite some change (albeit late might be better than never). Anyways, how about we start to do that from Factory / 11.2 on? That way it should be an automatic transition and doesn't confuse anyone.
Probably a better Vendor name would be prepending "openSUSE Build Service": "openSUSE Build Service (home:bitshuffler)", "openSUSE Build Service (KDE:KDE4:Communtiy)", etc. That way if someone wants the old behavior he could just create a file at /etc/zypp/vendors.d/ with [main] vendors=openSUSE Build Service ...well, I'm 99% about this.
Can we do this once we switch to 11.2 as separate distribution?
Adrian, what do you suggest?
This has nothing to do with forking of 11.2 because it is the exact same issue with Factory. Simply do it for Factory ASAP and then of course also for all future releases (e.g. 11.2) but don´t do it for already released versions (e.g. 11.1) to avoid the problems Michael explained in #1. For factory it shouldn´t matter because people normally use dup instead of up there anyways which doesn´t block vendor changes.
Yes, now fixed.
Reopening cause it is still broken. E.g. "trac" from the "devel:tools:scm" repo has as vendor obs://build.opensuse.org/devel:tools which should be obs://build.opensuse.org/devel:tools:scm See rpm -qp --queryformat "%{VENDOR} \n" http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/i586/trac-0.11.5-2.1.i586.rpm Another example: "kde3-amarok" from the "KDE:Backports" repo has as vendor obs://build.opensuse.org/KDE instead of obs://build.opensuse.org/KDE:Backports See rpm -qip --queryformat "%{VENDOR} \n" http://download.opensuse.org/repositories/KDE:/Backports/openSUSE_10.3/i586/kde3-amarok-1.4.10-38.3.i586.rpm My point is that _every_ repository has to have an _unique_ vendor, otherwise one isn't able to specify that a package should come from that _1_ repo and nowhere else which will lead to trouble sooner or later. Proposed resolution: Simply use the _whoole_ repository name as vendor string without cutting the last part of.
It's working like designed, it doesn't simply cut of the last part. It uses the same key as the vendor as for signing the packages. If you want a different vendor, create a different key. You can also overwrite the vendor setting in the project configuration.
After discussing with bitshuffler on IRC: The problem here might be that it breaks the vendor stickyness concept of zypper. For example when I have home:adrianSuSE with my stable releases and home:adrianSuSE:SVN-SNAPSHOT, the trust should be the same, because it is always me, so it is okay to use just one gpg key. But having one vendor for both projects would lead to the situation that it is not predictable if zypper stays with one of the repos for a package on update. So, I would consider to set the vendor to the building project, but not to the gpg key project.
Alternative, maybe better solution would be, if zypp would stick to repos, instead of to Vendors. Duncan, any opinion from you ?
Maybe do it both, first to try to stick to vendor and secondly also to the repo. This would be a straight forward development without becoming incompatible.
The only objection I have to Adrians comment #10 is that any compromisation of e.g. his home:adrianSuSE key also will compromise any of its subprojects - e.g. home:adrianSuSE:SVN-SNAPSHOT so using an unique key per repository is more secure.
if my home key is compromised, it is very likely that the other is also (and maybe all of OBS). Keys representing the people (groups), not their current intended work. So, if adrianSuSE from home:adrianSuSE steals your money and installs backdoors on your system, the adrianSuSE from :SVN is doing the same most likely.
*** Bug 544524 has been marked as a duplicate of this bug. ***
I suppose the repo thing can be done *now* since now there is http://en.opensuse.org/Libzypp/Package_History. But if I have to trust the wiki the repo is identified by the alias. Perhaps bnc#377568 should be fixed first.
I think the gpg key should be the same for sub projects. The vendor is not. The repo can't be unique identified, so it is not used for this comparison.
(In reply to comment #17) > I think the gpg key should be the same for sub projects. You want the same key for devel:*? ;-) Well, but I get your point. This could really be useful if implemented as a prjconf option: [x] inherit GPG key to subprojects (not sure if the subprojects need an option "don't use key from parent" ;-)
Well, what I mean is that the gpg key could be the same, if the trust of the repositories is the same. At least this is true for home:user:subprojects. If it is the same you have to deal with the consequence that you are trusting the whole sub-tree of repositories. For the vendor, yes, it may be the same as well, but it should not. If vendor is the same and a repo has chromium the browser and a subtree has chromium the game, they are threated as the same package.
I'm closing this bug as the implementation works as designed. Users who want different vendors for each subproject can do this in their project config. If you want to discuss this feature, please take it to the mailing list.
Reopening cause the solution is not acceptable. I don't care if you use different keys per project (I changed my mind in that regard and now agree with Adrian that it makes sense if some sub projects share the same key) but it is absolutely mandatory that every single project uses a different vendor since otherwise it is absolutely impossible to enforce that a package is only installed from a certain repository if repositories have the same vendor thanks to zypps vendor stickiness (which sadly enough wont change). Also "Users who want different vendors for each subproject can do this in their project config." might work fine for a build service that is totally under my control but it surely doesn't work for the public OBS and, probably quite understandable, I wont start writing every project owner a mail asking to do this. So the only sensible solution is to get rid of the pgp key <-> vendor link, generate unique vendors for all existing projects and generate unique vendors automatically for all new projects. Until that happens using zypp & OBS is a time bomb that will blow right in ones face sooner or later so please change your configuration.
And just to prevent any misunderstanding: I couldn't care less about the implementation details. My problem simply is that the current configuration of OBS just begs for trouble. Only if getting rid of the pgp key <-> vendor link means you have to change the implementation then so it be.
Please take this to the mailing list. Just reopening this bug wont convince me to change the code.
Well, then think about how to solve the following with the current setup of the _public OBS_: Project A:Foo contains Package1 (stable release) and Project A:Bar contains Package1 (svn snapshots, most time broken). Further A:Bar contains Package2 which I want to install as well. So we have the following situation: 1. Project A:Foo and A:Bar share the same key and therefore currently have the same vendor. 2. I want Package1 _only_ from A:Foo since the version in A:Bar is most times broken. 3. I also need to add Project A:Bar since it contains Package2 which I want to install as well. So how am I supposed to force zypp now to get Package1 only from A:Foo and not to constantly switch to the broken versions in A:Bar (which is newer but broken)? I honestly fail to see why it should be taken to the mailing lists and what there is to discuss since it is currently impossible and therefore obviously broken. And no, IMHO, writing people an email to ask them to please use separate vendors is no option since there are too many repos on OBS and the problem can arise out of nowhere as soon as someone adds some package somewhere. Also this problem would not exist if you would simply use unique vendors per repository. So, with all due respect, until you can come up with a solution for the above usecase _on the public OBS_ I dare to say that either the implementation or the configuration currently is broken and needs to be fixed.
Either use repo priorities or configure different vendors in the macro section of your projects' configurations (osc meta prjconf). I would use repo prios, as in that case 'zypper dup' (which ignores vendors) still works.
Well, editing the prjconf is no option cause the repos aren't under my control and using repo priorities wont work anymore if there's a package that is in both repos and which I would like to get only from A:Bar. OTOH if you would use unique vendors the problem wouldn't exist in the first place. Seriously, what is your problem with unique vendors per repository? As in why are you arguing that hard that this problem doesn't exist cause imho it is a pretty major one that turns zypp & OBS into a timebomb?
I just stumbled over this ancient bug - does this problem still exist? The current situation seems to be: - Vendor: contains the parent project (home:cboltz) - Distribution: contains the exact subproject (home:cboltz:something) Now the interesting question is if zypper reads Vendor: or Distribution: ;-)
Vendor contains the project used for signing the packages, so if you create a special key in your sub-project, it will be used as vendor instead of the parent. Zypper uses "Vendor".