Packages (e.g., python3-pybind11) that symlink to *.pc files in
/usr/{lib,share}/pkgconfig will have those links overwritten with actual
copies of the files after the hook
common/hooks/post-install/13-pkg-config-clean-xbps-cross-base-ref.sh
attempts to remove $XBPS_CROSS_BASE from paths. This will result in the
new copy containing corrected paths, but the original file remaining
uncorrected.
This was stolen fro @tornaria.
This should fix issues where -32bit packages are missing the runtime
dependencies, since the common/hooks/post-install/98-shlib-provides.sh
hook depends on the 32bit files being copied and the runtime and the
rdep part of the common/hooks/post-install/80-prepare-32bit.sh depends
on the common/hooks/post-install/98-shlib-provides.sh.
In a later change, we would like to generate runtime-deps between
sub-packages.
In order to do that, we can add everything into etc/shlibs or we can
look into other subpackages directly. The former is cumbersome if such
package has lot of shared-objects. The latter requires traversing and
checking a lot of files. Furtunately, we can speed up the latter one by
storing all shared-objects' information in a centralised place.
In a later change, we will generate shlib-depends cross subpkgs during
pre-pkg stage. Thus we need shlib-provides information of all subpkgs
ready before pre-pkg is run.
Those information can only be read in post-install stage at the
eariliest.
Let's move the shlib-provides to post-install. This hook requires
prepare-32bit, so, let's move that hook, too.
.tar.zst: bsdtar is built with support for it, so this shouldn't cause issues
.zst: zstd isn't in base-chroot, so it will need to be specified explicitly
We missed the case that distfiles was extracted to a single file.
Instead of changing the second leg, we can simply remove the third leg
because renaming the empty $extractdir to $wrksrc is the same of create
new empty $wrksrc
Some softwares insisted on have some manifest in top-level directory,
like package.xml for php packages. Some other packages was zipped on
macOS, which will insert some macOS metadata files into zoom.
See-also: dc73556cf3 and its parents.
See-also: 94fe74e506
Those files doesn't justify the need of adding a layer automatically
in extraction step.
Let's move them up.
Using a non-local `broken` variable in the hook
common/hooks/prepkg/04-generate-runtime-deps.sh
will cause a spurious shlib error when building templates marked broken
are built with `xbps-src -b`. Declaring the variable local is
sufficient, but let's make the name a bit more distinctive anyway.
Extracting to temporary directory then renaming to real $wrksrc,
will make the do-extract steps works atomicity. Either $wrksrc is there
and complete, or it's not there.
Accidentally, this change has a side effect, we can no longer care about
the name of top-level components of a tarball, since we will rename the
top level directory in question to $wrksrc. IOW, we don't need to set
$wrksrc any longer. The side effect of above side effect: we can starting
to build multiple packages that have same top-level's name without clean
from now on.
In another hand, we only rename the inner directory if the extracted
file hierarchy has single top-level directory, we will use the
renamed-temporary directory as the $wrksrc, $create_wrksrc variable is
no longer relevant, and do-clean will always work probably instead of
leaving some trash behind like before.
patch(1) has a -d/--directory parameter which allows us to specify a directory
where the patch will be applied. This is especially useful when we have
multiple distfiles and want to patch in $build_wrksrc because that's where the
patch is usually applied.
Problem is, that the -i parameter is also relative to the the -d parameter and
thus fails to find the patch, when -d is set. We solve that by using standard
input instead of -i.
The option `nostrip_files` takes a filename without path, in contrast to
option `nopie_files` which takes only full path.
This commit makes it so that `nostrip_files` can take either the
filename or the full path.
The -l option causes a looser behavior of patch(1), where patches
are applied when there is a match with no regard to leading
whitespace. This means that it is possible to get false positives:
for example, in srcpkgs/glu, there is a patch that was supposed
to be long gone (since the release already includes it) but it
was overlooked since with -l it happens to apply in a different
portion of the source (where it is wrong).
Avoid these cases.
Instead of using file(1) to check for ELF files, just read bytes
directly from the file and check if they are the ELF magic bytes.
Should probably be factored out into a common function that can be used
in other places, if necessary.
Also use awk instead of "grep|awk" for some minor speedup.
John
Andrew J. Hesford
q66
Đoàn Trần Công Danh
Duncaen
OpenSauce04
classabbyamp
Michal Vasilek
Piotr Wójcik
classabbyamp
tibequadorian
Gonzalo Tornaría
q66
Quentin Rameau
Érico Nogueira