On 29/9/20 6:53 am, Anatol Pomozov wrote:
Hi
On Thu, Sep 3, 2020 at 7:41 PM Eli Schwartz <eschwartz@archlinux.org> 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).
I'll repeat, we will never switch a default in a maintenance release. And the x.y.1 release usually happens within a couple of weeks as bugs are found. So that seems a pointless transition period. Moving it to 6.1 means a likely 18 month wait given our usual release cycle. I think we all agree the default should be not to include signatures in the repo database. The question is about timing. I don't think timing is up to when pacman makes a new release. It is up to the distro or repo provider, and providing a flag to revert to the old behaviour is all that is needed. I am of the opinion if people update a major part of their package provision infrastructure without reading the changes (which will be clearly stated in the release notes), then that is their problem, not ours. A