[pacman-dev] [Git][pacman/pacman][master] 7 commits: repo-add: add --include-sigs option

Allan McRae (@allan) allan at archlinux.org
Sat Sep 4 23:27:25 UTC 2021



Allan McRae pushed to branch master at Pacman / Pacman


Commits:
fbb29b50 by Allan McRae at 2021-09-04T19:52:23+10:00
repo-add: add --include-sigs option

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.

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
2109de61 by morganamilo at 2021-09-04T19:52:23+10:00
libalpm: take alpm_trans_t out of the public API

this type is only used internally by alpm

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
c5c6633d by morganamilo at 2021-09-04T19:52:23+10:00
libalpm: rename __foo tyes to _foo

__foo is reserved in c and should not be used.

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
e187aa9b by morganamilo at 2021-09-04T19:52:23+10:00
libalpm: use else when setting fingerprint

The docs [1] say keyid will always be there, so no need to check if it
exists.

[1] https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
625f3d64 by morganamilo at 2021-09-04T20:43:16+10:00
libalpm: don't use alpm_pgpkey_t in import question

When constructing an import question we never really used a proper gpg
key. We just zero initialize the key, set the uid and fingerprint, and
sent that to the front end.

Instead lets just give the import question a uid and fingerprint field.

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
be76f8bf by morganamilo at 2021-09-04T20:46:47+10:00
libalpm: add ALPM_TRANS_FLAG_NOHOOKS

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -
165e4924 by morganamilo at 2021-09-04T20:46:57+10:00
pacman: don't run hooks when using --dbonly

--dbonly is meant to only touch the database and not the actual system.
However hooks still run which can leave files in place or run commands
you may not want.

The hooks being run also means `fakeroot pacman -S --dbpath test/ foo --dbonly`
fails because alpm tries to chroot for hooks which requires real root.

Signed-off-by: Allan McRae <allan at archlinux.org>

- - - - -


15 changed files:

- doc/repo-add.8.asciidoc
- lib/libalpm/alpm.h
- lib/libalpm/alpm_list.h
- lib/libalpm/db.h
- lib/libalpm/diskspace.h
- lib/libalpm/graph.h
- lib/libalpm/handle.h
- lib/libalpm/package.h
- lib/libalpm/pkghash.h
- lib/libalpm/signing.c
- lib/libalpm/trans.c
- lib/libalpm/trans.h
- scripts/repo-add.sh.in
- src/pacman/callback.c
- src/pacman/pacman.c


View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/0a6fecd07271a54d9009ea7204c0e6288a44212b...165e492485aa7c3e3d94718dfdecf7a062f8af66

-- 
View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/0a6fecd07271a54d9009ea7204c0e6288a44212b...165e492485aa7c3e3d94718dfdecf7a062f8af66
You're receiving this email because of your account on gitlab.archlinux.org.




More information about the pacman-dev mailing list