This is a trickier situation.
The original message:
```
initend.c:423:10: error: ‘%s’ directive output may be truncated writing 15 bytes into a region of size between 1 and 512 [-Werror=format-truncation=]
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:422:3: note: ‘snprintf’ output between 16 and 527 bytes into a destination of size 512
snprintf(xhp->confdir, sizeof(xhp->confdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_SYSCONF_PATH);
~~~~~~~~~~~~~~~~~~
initend.c:429:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:428:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->confdir, sizeof(xhp->confdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initend.c:434:9: error: ‘%s’ directive output may be truncated writing 17 bytes into a region of size between 1 and 512 [-Werror=format-truncation=]
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:433:2: note: ‘snprintf’ output between 18 and 529 bytes into a destination of size 512
snprintf(sysconfdir, sizeof(sysconfdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_SYSDEFCONF_PATH);
~~~~~~~~~~~~~~~~~~~~~
initend.c:455:11: error: ‘%s’ directive output may be truncated writing 14 bytes into a region of size between 0 and 511 [-Werror=format-truncation=]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:454:3: note: ‘snprintf’ output between 16 and 527 bytes into a destination of size 512
snprintf(xhp->cachedir, sizeof(xhp->cachedir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_CACHE_PATH);
~~~~~~~~~~~~~~~~
initend.c:461:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:460:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->cachedir, sizeof(xhp->cachedir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initend.c:467:11: error: ‘%s’ directive output may be truncated writing 12 bytes into a region of size between 0 and 511 [-Werror=format-truncation=]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:466:3: note: ‘snprintf’ output between 14 and 525 bytes into a destination of size 512
snprintf(xhp->metadir, sizeof(xhp->metadir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_META_PATH);
~~~~~~~~~~~~~~~
initend.c:473:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:472:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->metadir, sizeof(xhp->metadir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
It's basically warning about dangerous operations on strings. And as
far as I could tell, is a valid warning and not a false alarm!
This fix makes the concept of `XBPS_MAXPATH` lose a little bit of sense
as now it doesn't necessarily represent the max size of the paths used
by xbps, but instead the max allowed size of the path configured.
I think this change is ok, but I wasn't able to find any reference to
why it was chosen to be 512. POSIX mandates at least 256, so I'm not
breaking anything that wasn't broken already, and Linux seems to have
a maximum size of 4096, which is pretty safe.
Therefore, this changes should be harmless. I think.
xbps_find_virtualpkg_in_conf() needs to look at the vpkgs set up in
configuration files, not from those set by pkgdb.
As a result of this the two test cases that were failing yesterday are now
fixed.
When adding packages to the index, xbps-rindex will check if the
consistency of shlibs is broken by a package. If so, rindex will create
a stage file and commit the packages there. Once the consistency is restored,
rindex -a will commit the stage area back to the public repo and delete the
stage file.
When adding packages to the index, xbps-rindex will check if the
consistency of shlibs is broken by a package. If so, rindex will create
a stage repository and commit the packages there. Once the consistency
is restored, rindex -a will commit the stage area back to the public
repo and delete the stage file.
Those are a wrapper around xbps_{array,dictionary}_internalize_from_zfile()
that prints a debugging msg when the plist file cannot be internalized.
Update xbps to use these wrappers.
We use a simple file lock that is created with O_CREAT|O_EXCL.
This should fix the concurrency issues with multiple processes
running xbps-rindex -a/-c on the same repository/arch combo.
At the time we've been searching for the pkg in a repo, no repos
were registered resulting in EINVAL. While here, if there's no
declared repos return ENOENT instead.
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).
If xbps_repo_open() was called with the lock arg set, xbps_repo_close()
will now unlock the repo file lock, without the need to set it.
This avoids the need to always unlock the file lock even if it wasn't
locked previously. This also introduceds an ABI/API break, but this
way it's cleaner.
- Simplify xbps_repo_open::repo_get_dict().
- Use xbps_end() in the utils where necessary.
- Make xbps_end() call xbps_pkgdb_unlock() if necessary.
- Make xbps_end() release rpool resources.
- Make xbps_end() release resources from xbps_handle.
- Fixed 90% of reported leaks (still reachable at exit) from valgrind.
That was to silence valgrind's memcheck with --leak-check=full.
-i, --ignore can be specified multiple times and can be used to
ignore configuration of those packages while configuration of all
packages is being performed.
Close#67
This explicitly enables the in memory fetch/store of remote repository
data archives mode, ignoring existing on-disk repodata archives.
This changes the previous behaviour of falling back to this mode if no
on-disk repodata archives were found.
Thanks to @Gottox and @dominikh for comments.
These routines return a xbps_array_t with a full sorted dependency graph
for the target pkg, by querying pkgdb or rpool.
Update xbps-query(8) to use the new libxbps API.
This allows you to print to stdout any file stored in a binary package,
locally or remotely!
$ xbps-query -R --cat=/usr/bin/ls coreutils > ls
$ file ls
ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=7a195fc46d1d5cdca32bfccd3b30f81784e342ed, stripped
$
- This mode prints to stdout the matching FILE stored in a binary package.
- ABI break: renamed xbps_get_pkg_plist_from_binpkg() xbps_binpkg_get_plist().
- Added xbps_binpkg_get_file() as a generic way to get pkg file contents.
- Removed useless comments from xbps_api_impl.h.
The behaviour of this routine mimics the existing xbps_array_add() with
the difference that stored objects are moved to the right to insert
our object as the first element on the array.
Use this to add replaced packages in the transaction array at the head
rather than at the end, to preserve the proper sorting order.
