It should be HAVE_HUMANIZE_NUMBER instead of HAVE_HUMANIZE_HUMBER, from
the name of humanize_number(3).
It's mispelt only in this file, the configure script gets it correctly.
Closes: #334 [via git-merge-pr]
The width of unsigned long matching the width of a pointer isn't
guaranteed by any standard, though it is a requirement of the Linux
syscall API. Using uintptr_t directly is always correct.
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.
- Added transaction stats for pkgs on hold.
- Always add packages on hold to the transaction dictionary,
its type will be set to XBPS_TRANS_HOLD.
- Changed xbps_transaction_update_pkg() to have a new "force"
bool argument to force an update with a pkg on hold.
- As discussed in #274 with @Duncaen the only way to update a
pkg on hold is by using `-f`, i.e `xbps-install -f foo`.
Closes#265Closes#274
- xbps_repo_release(): new function to release all resources
associated with a repository object.
- xbps_repo_close(): this now just closes the file descriptor
associated with the archive and associated resources.
- repo_open_local: after getting the repository dictionaries,
use xbps_repo_close() to release archive resources.
Bump XBPS_API_VERSION.
This commit implements multiple performance improvements
to the transaction code:
- Don't process xbps_pkg_name() N times each time we access
its package dictionary (via pkgdb or rpool), just do it once
at xbps_pkgdb_init() time. At pkgdb init time, it just creates
a property in pkgdb, "pkgname". At rpool time, each time a
package is accessed, the "pkgname" string property is added.
- The package transaction dictionary contains the "transaction"
object to know what's the pkg type. This has been changed to an
uint8, this simplifies the logic and it's faster than checking
a string object. See xbps_trans_type_t and xbps_transaction_pkg_type().
- Fixed the issue that was marked with XXX in transaction shlibs
checking code. This has been fixed and improved and resources are
now just freed as expected.
- Simplified random code all over the place, avoiding unnecessary
allocations or operations.
- Rename some transaction files to have a better description.
This is my first rototill to the code in 2020.
Add configuration option keepconf that stops xbps from overwriting
unchanged configuration files. If keepconf=true, xbps will store the new
configuration as <name>.new-<version> instead of overwriting unchanged
configuration files.
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.
When there's a new xbps update, xbps-install(1) will now return
EBUSY (16) and a message (if dry-run disabled) explaining
how to proceed.
If there's an update and transaction does not contain xbps, it will
error out unless the 'xbps' pkg is the only target pkg, i.e:
# xbps-install -Su
# echo $?
16
To update xbps, the only way to proceed is to explicitly declare
it as an update, i.e:
# xbps-install -u xbps
The dry-run mode will still show there's an xbps update.
Modified the existing test cases to satisfy the new behaviour.
Closes#166Closes#142
`xbps_transaction_revdeps` will now try to add updates for packages to the
transaction if the dependency is not satisified anymore due to a package
install/update.
`xbps_transaction_prepare` will now check the return value of
`xbps_transaction_revdeps` and repeat the dependency resolution,
until `xbps_transaction_revdeps` returns 0, which means that it didn't
add any new packages to the transaction.
Added `-D, --download-only` flag to allow downloading
packages to the cache without attempting to install them.
Contributed by Toyam Cox via #9
Adapted to master by yours truly.
Close#9
If set it will continue with the transaction and will
just print what are the conflicting files without returning
EEXIST.
This is a temporary solution for void where there are still
some packages with conflicting files (qt5-host-tools vs qt5-tools-devel).
With input 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.
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.
