[pacman-dev] [PATCH] repo-add: add --include-sigs option

Allan McRae allan at archlinux.org
Sun Oct 4 05:01:59 UTC 2020


On 29/9/20 6:53 am, Anatol Pomozov wrote:
> Hi
> 
> On Thu, Sep 3, 2020 at 7:41 PM Eli Schwartz <eschwartz at 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


More information about the pacman-dev mailing list