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.
> >
> > diff --git a/doc/repo-add.8.asciidoc b/doc/repo-add.8.asciidoc
> > index 8de4485b..19e2336a 100644
> > --- a/doc/repo-add.8.asciidoc
> > +++ b/doc/repo-add.8.asciidoc
> > @@ -70,6 +70,10 @@ repo-add Options
> > Remove old package files from the disk when updating their entry in the
> > database.
> >
> > +*\--include-sigs*::
> > + Dummy option for forward compatibility with pacman-6.0.
> > + Include package PGP signatures in the repository database (if available)
> > +
> >
> > Example
> > -------
> > diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in
> > index b0b3505d..ee010dba 100644
> > --- a/scripts/repo-add.sh.in
> > +++ b/scripts/repo-add.sh.in
> > @@ -43,6 +43,7 @@ LOCKFILE=
> > CLEAN_LOCK=0
> > USE_COLOR='y'
> > PREVENT_DOWNGRADE=0
> > +INCLUDE_SIGS=0
> >
> > # Import libmakepkg
> > source "$LIBRARY"/util/message.sh
> > @@ -631,6 +632,9 @@ while (( $# )); do
> > -p|--prevent-downgrade)
> > PREVENT_DOWNGRADE=1
> > ;;
> > + --include-sigs)
> > + INCLUDE_SIGS=1
> > + ;;
> > *)
> > args+=("$1")
> > ;;
> > .
> >
