Am Thu, 18 Dec 2008 10:22:25 -0600 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
On Thu, Dec 18, 2008 at 7:02 AM, Gerhard Brauer <gerbra@archlinux.de> wrote:
I've not tested your patch (today evening maybe), but i am not very happy with this triple state. If i choose to use a repo which offers signed packages then i want the "full program", so if something wrong with one package i don't want it get installed/upgraded. And if i have a repo without signing then i don't put the option in the repo section of pacman.conf.
I think "Optional" makes sense in some cases. Let's take the community repo, where things tend to be a hodge-podge of ideas and attitudes. I can imagine half the packages being signed, some being unsigned, and some being signed by keys not in the keyring.
If we wan't this (or if the [community] situation lead us to MUST wan't this) then such a "Optional" is ok IMHO (with a pacman warning...) But the question (also the TU's must discuss this) is: why not also sign community packages per policy? - The build tools (where signing is integrated) are both the same for developers and TUs. - Also the TU's have the same interest like the devs that their packages are on good integrity when they leaves their machines and that this could be checked before the users installed these. (we make this signing thing not for funny ;-) - Only TU's(and Devs) putting packages in community, so the count of needed keys is not soo much. But TUs come and go more often than Devs, so a separate keyring makes sense IMHO cause it changes often. So if we find a solution to avoid this "Optional" setting, that would be better IMHO. (To clear: I'm neither a Dev nor a TU (and badly also not a C programmer...), my suggestions comes most from the "user side" of this theme... But i like always to say: "We" <g>) Regards Gerhard