On 21/9/20 3:51 pm, Andrew Gregory wrote: > On 09/21/20 at 03:19pm, Allan McRae wrote: >> On 4/9/20 12:55 pm, Allan McRae wrote: >>> On 4/9/20 12:40 pm, Eli Schwartz wrote: >>>> On 9/2/20 11:02 PM, Allan McRae wrote: >>>>> Pacman now downloads the signature files for all packages when present in >>>>> a >>>>> repository. That makes distributing signatures within repository >>>>> databases >>>>> redundant and costly. >>>>> >>>>> Do not distribute the package signature files within the repo databases by >>>>> default and add an --include-sigs to revert to the old behaviour. >>>> >>>> As I've mentioned on the list before, I would like an --ignore-sigs >>>> option and continue to distribute sigs by default for pacman 6.0 >>>> >>>> In pacman 6.1 we'll switch by default to ignoring them, and let people >>>> use --include-sigs to revert to the old behavior. >>>> >>>> Ignoring sigs right out of the gate means the default behavior of >>>> repo-add is to be unusable for people upgrading from pacman N-1. For >>>> example, Arch Linux would most certainly need to use the option to >>>> provide backwards compat while upgrading. So do third-party repositories. >>>> >>>> Also: this option cannot be added to scripts ahead of time, since >>>> repo-add will error on an unknown option, and it cannot be added after >>>> the fact, since some packages will be broken in the meantime. >>>> >>>> I don't see what the rush is here to add behavior that no one will want >>>> to use. >>>> - It makes sense to make this configurable now that it's useful to be >>>> able to ignore them. >>>> - At the same time, defaults should be based on what is more likely for >>>> people to want. >>>> >>> >>> I really do not like the idea of adding an option, just to remove it in >>> the next release. But we won't actually be able to remove it for at >>> least two releases, as you have just made the case that people won't be >>> able to change their scripts on release. >>> >>> Given pacman-6.0 is likely a few months out, can we do a 5.2.3 release >>> including something like: >>> >> >> Any feedback on this option? > > 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. Allan