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. -- Eli Schwartz Bug Wrangler and Trusted User

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

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. 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). -- Eli Schwartz Bug Wrangler and Trusted User

Hi On Thu, Sep 3, 2020 at 7:41 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

I agree with Eli here. "Using embedded signatures" should stay default as long as we support clients with pacman 5.x version. Otherwise we are going to hit problems when a repo maintainer updated their system to pacman 6.x and started distributing optimized databases without signatures while some clients still expect embedded sigs. So I vote for including sigs by default in pacman 6.0 release, and then flip the default later (during 6.0.1 or 6.1 release).