Bug 186636

First of all, it is in libzypp, not in zmd.

To understand this better, let us see why the lock exists: it is to prevent the package from being overwritten by a "newer" one (with newer version but from Novell) from a newer release of the product when we are doing an upgrade.

1) yes.

2) IMO does not make sense. The USER must make the decision, not the repo creator.

3) is going a step further, attempting to aid the upgrade process. But we still have a problem when having foo-1-0utx installed and having a choice between foo-1-1 and foo-1-1utx. (maybe we could prefer the candidate with the same vendor?)

2+3) If installation source will set the "unlocked" flag, then the installation source maintainer should be responsible for having up-to-date versions.

You can also limit (at least automatic) cross-vendor updates, warn user or create one new "locked" status - "vendor-locked".

Example:
"You have foo-1-0utx" installed from vendor "UTX". Newer package foo-2-0novell from different vendor "Novell" exists. Do you want to update?"

"Lock package" "Lock package to vendor" "Skip" "Update"

This needs more locking information -> Michael (to think about it ;-))

I don't know about the more advanced steps, but let's discuss the configurability.

How about adding /etc/sysconfig/zypp:TRUSTED_VENDORS, Michael?

There is a technical issue about storing a list of arbitrary(?) strings in a sysconfig variable but I think we could just use comma as the separator.

It would also be useful if one could lock certain packages if one wanted to from a repo creator's perspective.  Currently, the only way to do that (on purpose) is to omit the Vendor tag -- but that's not possible if you can't rebuild the rpm. 

A facility to either lock or unlock packages by the repo creator is actually useful and a use case: sometimes, the repo creator knows better than the user as to which pacakges are more compatible with which.   The user should also be given the mechanism to override those decisions, of course.

Ping
We have already issue with this feature on SLES9. We will certainly same problems in SLES10 SP1 see bug #250340

What is status of this bug?

There should be no isssue on SLES9, as you can configure the trusted vendors.

libzypp-2.15.4 supports this as well. Some documentation is still missing. 
But I suppose it will be on SLES10 SP1. 

Could you please close this bug after some documentation will be available?

http://en.opensuse.org/Standards/Libzypp_Store#db.2FtrustedVendors

Thank you.

First: Thanks for adding this option!

But I have two additional requests (give me a small finger, I take your whole hand...):

1) 
Could you add and example (for the "buildservice vendor") in the wiki?

2) 
I think users complaining with the FHS would expect such a file somewhere in /etc. What about an additional directory like "/etc/libzypp" (if you add more "custom variables" later) or just a /etc/sysconfig/libzypp file?

With /etc/sysconfig/libzypp, this option would become more "popular" because users can edit the settings using YaST.

@1) It's wiki. If you happen to know the "buildservice vendor", feel free to add it. 

@2) The option should not become too popular, because it is a workaround. The core problem is the concept of locking packages based on their vendor. We have to get rid of that. Vendor comparison should determine the preferred candidate to update a package, and it should tell whether an update can be performed automatically or requires user confirmation. But not autolock some package in general. 

We will use /etc, but not for this one.