On 23/9/20 12:27 pm, Eli Schwartz wrote: > On 9/21/20 3:02 AM, Allan McRae wrote: >> On 21/9/20 3:51 pm, Andrew Gregory wrote: >>> I would suggest just allowing the user to specify either way >>> (--include-sigs/--no-include-sigs, --include-sigs={yes,no}, etc). >>> Then uses can specify whatever they want without having to worry about >>> what we set as a default. >>> >> >> The problem is more the transition. I would like the default to be not >> to include the signatures in the repo database. So does pacman need to >> manage the transition from having signatures in a database to not, or do >> the users need to manage that? >> >> With my patch (or any variant the does not include signatures by >> default), users upgrading to repo-add v6.0 would need to adjust their >> repo management utilities to add a signature include option immediately, >> as their users may still be using pacman-5.x. >> >> Thinking of Arch here, a dbscripts update would need launched on the >> server at the same time as updating repo-add. I am OK with that - some >> updates need done in concert. But Eli was not. > > I'm concerned both about the need to time the adjustment of the option, > and about the desire for what I see as sane defaults. > > My preference is to provide both options, but change the default in > pacman 6.0.1.
We are not making a behaviour change in a point release. > While we're hacking on repo-add options, we could go ahead and make it > use parseopts, because the current handling is gross. Also I would like > an elephant (usually I would request a pony, but this felt more apropos > if we're talking about repo-add). I'm not touching repo-add beyond the most minor of changes. A sync db writing backend should be added to libalpm and repo-add replaced with something more easily extended. Allan