Reworks the UI of -F according to FS#47949
In short -F replaces both -Fs and -Fo.
Searching for an exact path (target contains "/"), causes the output to
switch to the old -Fo output. Otherwise the old -Fs output is used.
Also strip the leading "/" from targets like how -Qo does.
Signed-off-by: Allan McRae <allan@archlinux.org>
When scripting/automating around makepkg, it is sometimes desirable to
know how makepkg will be configured to operate. One example is the
archlinux devtools, which must forward select makepkg.conf variables
into a build chroot (for example PACKAGER) or use those variables itself
(for example {SRC,PKG,LOG}DEST).
The configuration file can be in up to 3 places, and should be capable
of being overridden via environment variables. It is sufficiently
complex to represent distinct functionality, and sufficiently useful to
merit easy accessibility in other scripts, therefore, let us move it
into a publicly exposed utility library.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Currently this tells people that the settings should not be touched, but
we should just rely on the description of what it should be set to, and
leave it up to the user. With the previous patch, makepkg aborts if an
invalid value is set, greatly reducing the danger of it being badly
configured.
Also make this clearer by indicating when it would be useful to change
the settings -- i.e. disable compression -- and ensure their described
defaults are based on the ones established during ./configure or meson
setup.
Reported-by: Jouke Witteveen <j.witteveen@gmail.com>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
These variables must begin with .src.tar / .pkg.tar respectively, so
fail early if those expectations are not matched. This prevents makepkg
from creating e.g. package files literally named "./pacman-5.1.3-1-x86_64"
which are actually uncompressed tarballs.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
file 5.37 changed the gzip MIME type from application/x-gzip to
application/gzip, so support this when checking to extract source files.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Since makepkg exports a public library of functions, other projects may
wish to use these functions. Highlights include parseopts or our
messaging functions.
Install a pkg-config file in order to let downstream users detect where
they can source the libmakepkg functionality. This is useful e.g. to
gracefully handle the case where a thirdparty project is configured and
installed into a different datarootdir from pacman, but still wants to
use the installed pacman's version of libmakepkg.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
When the executable checking was refactored into libmakepkg, it carried
with it, usage of $E_* error codes, which need to be declared from
error.sh but are only available when the parent program already sources
error.sh; additionally, message.sh was only loaded in a parent
library, but not where it was needed, and option.sh was often loaded
when it wasn't needed at all.
util.sh, meanwhile, has always depended on message.sh functions.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The right-hand side of the [[ ... = ... ]] keyword is an exception to
the general rule that quoting is unnecessary with [[
This is usually not a problem, e.g. in libmakepkg, lint_one_pkgname will
already fail if pkgname has an asterisk, but it certainly doesn't hurt
to be "more proper" and go with the spec; it is more dangerous in
repo-add, which can get caught in an infinite loop instead of safely
asserting there is no package named 'foo*'.
Reported-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Fixes "arch" and "checkdepends" never having been unset, fixes b2sums
(but not ${!b2sums_@}) being recently left out.
The "build" function used to be unset as well, explicitly unset it as a
function and do the same for other official functions as well.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The libarchive header is used in alpm.h, and several binaries include
this header. This is noticeably a problem when using e.g. the musl-gcc
compiler which does not include /usr/include by default, and thus the
build system reports:
...../lib/libalpm/alpm.h:35:10: fatal error: archive.h: No such file or directory
More commonly, this will result in compiling against potentially the
wrong headers, if the libarchive installation picked up by pkg-config is
different from the one with headers in /usr/include, and /usr/include is
in the -isystem path.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
In commit b5191ea140 we moved to using
shell globbing to print package files for a couple of reasons including
reproducible packaging of .METADATA files.
Unfortunately, this only works reliably when the glob pattern does not
resolve to a symlinked directory due to a change in the bash 5.0
release. Note that the previous, desired behavior was rather to merely
refuse to recurse into symlinked directories, but due to an unrelated
issue, the symlink handling for globstar was reworked in a way that had
this side effect.
See https://lists.gnu.org/archive/html/bug-bash/2019-04/msg00015.html
for discussion; this may be fixed at some point, but bash 5.0 is broken
either way.
The appropriate way of handling this seems to be to use **/* to match
instead; this produces the same results on both bash 4 and bash 5, as
the ** matches any leading directory component (or none), and the *
matches any file, directory, or symlink to either one.
Fixes FS#62278
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Clang 8 warns that adding a string to an integer does not append to
string. Indeed it doesn't, but that was not the intentetion. Use array
indexing as suggested by the compiler to silence the warning. There
should be no functional change.
Example of warning message:
alpm.c:71:54: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
sprintf(hookdir, "%s%s", myhandle->root, SYSHOOKDIR + 1);
~~~~~~~~~~~^~~
alpm.c:71:54: note: use array indexing to silence this warning
sprintf(hookdir, "%s%s", myhandle->root, SYSHOOKDIR + 1);
^
& [ ]
1 warning generated.
The "tip" ref actually signifies the most recently updated branch. hg
does not support a default branch named anything other than "default",
except by creating a "@" bookmark. The correct way to explicitly update
to the default clone ref, is therefore to use one of these, rather than
"tip".
Fixes FS#62092
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
One of the callers was changed to use known_hash_algos, one was not.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The current completions don't properly handle redirection operators, and
attempt to complete command completions rather than completing filenames
to redirect to.
bash-completion provides both _get_comp_words_by_ref and a higher-level
wrapper _init_completion, but the latter provides handling of redirection
operators, so switch to using that.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Currently this is scoped to the build() function, which is simply wrong
as it equally applies to any function. Simply moving the paragraphs up
to the main manpage section makes this clear.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
In commit 1825bd6716 this was split out
from makepkg, but the warning was not properly migrated; $ext did not
ever exist.
As a result, no matter what you did, the only possible warning was:
==> WARNING: '' is not a valid archive extension.
Fix to filter based on the presence of .tar in the argument, and
building the $ext variable for all checking and messaging purposes
within the function.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
In order to cache sources offline, makepkg creates *two* copies of every
git repo. This is a useful tradeoff for network time, but comes at the
cost of increased disk space.
Normally, git can smooth this over automagically. Whenever possible, git
objects are hardlinked to save space, but this does not work when
SRCDEST and BUILDDIR are on separate filesystems.
When the repo in question is both very large (linux.git for example is
2.2 GB) and crosses filesystem boundaries, this results in a lot of
extra disk space being used; the most likely scenario is where BUILDDIR
is a tmpfs for bonus ouch.
git(1) has a builtin feature which serves this case handily: the
--shared flag will create the info/alternates file instructing git to
not copy or hardlink or create objects/packs at all, but merely look for
them in an external location (that being the source of the clone).
The downside of using shared clones, is that if you modify and drop
commits from the original repo, or simply delete the whole repo
altogether, you break the copy. But we don't care about that here,
because
1) the BUILDDIR copy is meant to be a temporary copy strictly derived
via PKGBUILD syntax from the SRCDEST, and must be able to be
recreated at any time,
2) if the SRCDEST disappears, makepkg will redownload it, thus restoring
the objects needed by the BUILDDIR clone,
3) if the user does non-default things like hacking on the BUILDDIR copy
then deleting and re-cloning the SRCDEST may result in momentary
breakage, but ultimately should be fine -- the unique objects they
created will be stored in the BUILDDIR copy.
While it's theoretically possible that upstream will force-push to
overwrite the base tree from which makepkg is building (which they
should not do), *and* the user deleted their SRCDEST which they should
not do, *and* they saved work in makepkg's working directory which they
should not do either...
... this is an unlikely chain of events for which we should not care.
Using --shared is therefore helpful in immediately useful ways and IMHO
has no actual downsides; we should use it.
An alternative implementation would be to use worktrees. I've rejected
this since it is essentially the same as shared clones, except adding
additional restrictions on the branch namespace, and could potentially
break existing use cases such as manually handling the SRCDEST in order
to share repositories with normal working copies.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
gpgme in git master now supports pkg-config and with the next release we
can and should prefer its use. However, retain the legacy code that
enables building with older versions of gpgme, as a fallback.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Since DUFLAGS and DUPATH are not needed anymore remove them from the
source
Signed-off-by: Santiago Torres <santiago@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
MODECMD and OWNERCMD are not used by pacman itself, so we don't need to
check for and replace them now that pacman-optimize is removed.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Makepkg used to use du --apparent-size to compute the size of the
package. Unfortunately, this would result in different sizes depending
on the filesystem used (e.g., btrfs vs ext4), which would affect
reproducible builds. Use a wc-based approach to compute sizes
Signed-off-by: Santiago Torres <santiago@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The time logged is currently given as localtime without any timezone
information. This is confusing in various scenarios.
Examples:
* If one is travelling across time-zones and the timestamps in the log
appear out of order.
* Comparing dates with `datediff` gives an offset by the time-zone
This patch would reformat the time-stamp to a full ISO-8601 version.
It includes the 'T' separating date and time including seconds.
Old: [2019-03-04 16:15]
New: [2019-03-04T16:15:45-05:00]
Signed-off-by: Florian Wehner <florian@whnr.de>
Signed-off-by: Allan McRae <allan@archlinux.org>
Dummy callbacks are still present to prevent compiler warnings until
libalpm is delta free.
Also remove Delta parsing from pacman.conf.
Signed-off-by: Allan McRae <allan@archlinux.org>
If an alternative rootdir is specified in either meson or configure it's
not respected in the generated man pages.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
Signed-off-by: Allan McRae <allan@archlinux.org>
coreutils 8.26 in December 2016 added this new hashing method which is
compatible with the existing md5sum and sha*sum tool usage, while using
the blake2 hash algorithm.
makepkg uses coreutils to provide source file integrity checks via
${integ}sum binaries and it makes sense to offer this as an additional
option.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
When installing a remote package with "pacman -U <url>", pacman renames
the downloaded package file to match the name given in the
Content-Disposition header. However, pacman does not sanitize this name,
which may contain slashes, before calling rename(). A malicious server (or
a network MitM if downloading over HTTP) can send a content-disposition
header to make pacman place the file anywhere in the filesystem,
potentially leading to arbitrary root code execution. Notably, this
bypasses pacman's package signature checking.
For example, a malicious package-hosting server (or a network
man-in-the-middle, if downloading over HTTP) could serve the following
header:
Content-Disposition: filename=../../../../../../usr/share/libalpm/hooks/evil.hook
and pacman would move the downloaded file to
/usr/share/libalpm/hooks/evil.hook. This invocation of "pacman -U" would
later fail, unable to find the downloaded package in the cache directory,
but the hook file would remain in place. The commands in the malicious
hook would then be run (as root) the next time any package is installed.
Discovered-by: Adam Suhl <asuhl@mit.edu>
Signed-off-by: Allan McRae <allan@archlinux.org>
Rather than use M/s which can be either MB or MiB, specify that it uses
MiB (consistent with the displayed total size).
Fixes FS#59201
Signed-off-by: Sever Oraz <severoraz@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
shared_library does not generate a sane pkg-config file because it
assumes we don't want dependencies.
Additionally, since we key off of buildstatic, when *not* using
buildstatic but attempting to build libalpm on its own as static using
-Ddefault_library=static, we are building and linking to a shared
libalpm anyway.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
We cannot use most of the arrays defined in schema.sh as srcinfo is dependent
on the order, but migrate the hashes for now.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
We don't need to check the options twice, since it is the same check
both times. Instead, merge the conditionals.
As far as I can tell, the only reason the checks for:
- PACMAN_OPTS and
- whether to use sudo
were ever separated is due to the historic existence of --asroot, since
the second check included a check for (( ! ASROOT )) until it was
cleaned up in commit 61ba5c961e.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
When pacman is run as root to do -S, -U, or -R, it would immediately
abort if pacman is not ready for use. Instead, poll the lockfile and
wait until it becomes available.
Implements FS#28840
Original-patch-by: Georges Dubus <georges.dubus@compiletoi.net>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
This has historically been the case in autotools since we want vercmp to
not break mid-transaction in an install script.
For convenience, we create libalpm.a and use this to optionally generate
libalpm.so (when not configured with -Dbuildstatic=true) as well as to
link any binary which explicitly wishes to be built statically "with
libalpm", but does not care where a function is defined. meson then
treats this correctly: it builds the object file only once for both
libraries, and the compiler strips out unused functionality from the
final static binary.
Currently the only binary which requires this is vercmp.
Fixes FS#61719
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Requires modification to our comment about fall through to match compilers
expectations. Works for GCC and Clang.
Signed-off-by: Allan McRae <allan@archlinux.org>
If a mirror responds with a 301 redirect to itself, it will create an
infinite redirect loop. This will cause pacman to hang, unresponsive to
even a SIGINT. The result is pacman being unable to sync or
download any package from a particular repo if its current mirror
is stuck in a redirect loop. Setting libcurl's MAXREDIRS option
effectively prevents a redirect loop from hanging the process.
Signed-off-by: Mark Ulrich <mark.ulrich.86@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Variables such as 'pkgdesc_x86_64' are invalid, instead of ignoring them
raise an error.
This also disallows using 'any' as an architecture specific variable
Signed-off-by: morganamilo <morganamilo@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
