This ensures we take user specific config values for PKGDEST into
account when printing the package list. This is required as devtools
archbuild_cmd puts packages potentially into the user defined PKGDEST
which the package list would otherwise miss.
This fixes an issue with the usage of makepkg --packagelist to get the
produced artifacts filenames according to the PKGEXT used in devtools'
makepkg.conf instead of the one defined in pacman.
One goal we want to preserve is that devtools configuration should be
self contained and not require any editing of non owned files like
the host /etc/makepkg.conf to produce expected results.
Additionally modify the archbuild_cmd override for multilib builds to
use an independent variable and not fiddle with the actual arch
variable to select the appropriate cmd.
This ensures we use the same configuration for reproducing packages as
we use for building them via devtools.
One example of why we care about this are the COMPRESS* settings that
may differ from the guest's pacman shipped makepkg.conf that affect the
reproducibility of packages.
We don't want the default PKGEXT in the current version of devtools, we
want the PKGEXT we *know* the input file used.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
We need to modify the matching of valid package files to support formats
like zstd. Let's try to use an eager approach instead of a simple
whitelist in order to be functional for arbitrary formats that may be
introduced in the future without the need to adjust any code.
Allow any single fragment word as compression type but filter out known
non-package content like signature files.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
This means that the remote command died at some stage earlier than the
printing of created files.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Use pacman's --dbpath feature to sync fresh databases inside an isolated
location and split up the database sync and package location calls to
remove the need of weird grep calls.
It isn't nice of makechrootpkg to modify the host database state just by
building packages. No foreign program shall automatically modify
the host database other than by the explicit will of a system
maintainer, which is the major reason this changes get incorporated.
However, there is certain indoctrinated believe that using -Sy is
the prime evil. In fact it has been declared as a social rule to a
technical problem of not getting into potential partial upgrade states.
This is not a proper loophole less solution as there are multiple ways
and use cases that lead to such a state, like aborting a -Syu on the
prompt for whatever reason, what really matters is that it is not a
technically bullet proof solution to solve the problem.
Databases shall have the freedom to be as up to date as databases or
their owner wishes, allowing querying on latest database state without
fear. The only loophole-less contract that _really_ is from importance
is always using -Su instead of plain -S to install packages. Installing
packages is what actually brings one into a potential partial upgrade
state and by using -Su an outstanding upgrade is forced when installing
a new package. This properly solves all edge cases in a technical
manner instead of declaring people who abort the prompt of -Syu to be
the problem. In fact, using this simple contract allows whatever system
maintenance workflow a host owner wants to follow, which may still be to
always use -Syu and deal with system upgrades explicitly instead of the
time when installing new packages, but the -Su contract is the real safe
guard to guarantee no edge case can ever slip in. This magically also
opens up the freedom to people who wish to use -Sy to simply query on up
to date data as the currently indoctrinated "never do -Sy" stone plates
not only are not rock solid in technical terms but also make certain use
cases simply impossible and hence cripple the functionality without at
the very least being fully loophole free.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
