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