Since 8d5c48b, xbps has used a sha1 ASN1 prefix with a sha256 hash, and
as of openssl v3, openssl cares about this. This works around that in a
compatible way by moving to a second sig file, binpkg.sig2.
For xbps-remove -O and xbps-rindex -r, also clean up obselete .sig files.
This reverts commit be7d8cfaf1.
This commit missed some previous copyrights mentioned,
in general I think its better to have this per-file to
follow who wrote what and when.
The funcs xbps_pkg_name() and xbps_pkgpattern_name() were
using malloc(3) to return the result, until now.
They now have been changed to not allocate the result
via malloc, the caller is responsible to provide a buffer
at least of XBPS_NAME_SIZE (64).
If for whatever reason the pkgname can't be guessed,
returns false. This should avoid lots of small allocs
around libxbps.
New functions have the following prototype:
bool xbps_pkg_name(char *dst, size_t len, const char *pkg)
bool xbps_pkgpattern_name(char *dst, size_t len, const char *pkg)
as suggested by @duncaen.
The previous idea was to use virtual packages in the users configuration
to satisfy dependencies by mapping them to existing installed packages.
Using virtual packages for it doesn't work as expected and trying to make
it work would break other functionalities of virtual packages, like the
version satisfaction checks for `provides` and the ability to replace
virtual packages with real packages. The virtual package functionality
should be used exclusively for virtual packages.
This allows users to specify packages packages that should be ignored.
Ignored packages in dependencies are always satisfied without installing
the package, while updating or installing a package that depends on an
ignored package.
This does NOT ignore the shlib checks, ignoring a package that provides
required shared libraries will abort the transaction as if there was no
package that provides the required shared library.
There's no reason to make them absolute, simply store in the metadata
the target file as is. This vastly simplifies the code and makes all
test pass correctly.
If xbps-create(8) did not guess the target file of relative symlinks for
some reason, just compare the current symlink and what's stored as is,
without converting it to absolute.
This might happen with dangling relative symlinks or existing binary
packages that were not created with a newer xbps-create(8).
- xbps_binpkg_pkgver() returns a heap allocated string with the pkgver component.
- xbps_binpkg_arch() returns a heap allocated string with the architecture component.
A basename, full path or relative path is supported, i.e:
/path/to/foo-1.0_1.x86_64.xbps
../../foo/blah-0.1_1.x86_64.xbps
baz-0.1_1.x86_64.xbps
The reason is that even if the pkg was not configured, it should still be accepted
as installed. If installing packages via XBPS_TARGET_ARCH, pkgs are never configured,
so this must be taken into account.
Will be cherry-picked to 0.37 meanwhile.
