Previously xbps just ignored hold packages, now it will exit
with an error code in case there is a dependency conflict
with a held dependency since it would previously result
in inconsistent dependency state.
Deleting obsolete directories is different from deleting obsolete files,
files need to be deleted by the first package that might change the file
into a different file type.
Directories need to be deleted by the last package that removes files
out of the directory to avoid ENOTEMPTY if another package has a file in
the given directory which is uninstalled later.
This fixes#282.
- 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
I noticed that while updating a pkg that is on hold
or in repolock mode, does not keep those properties.
Always set those props in the new pkg dictionary to respect
this behaviour. If there's a pkg on hold and you update it,
you want to keep it in this state unless you tell it to change.
Added new test case to verify.
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.
This change ensures that no multiple versions of the same pkg
are added to the transaction; if a new version of the same
package is being added as a dependency, compare stored
and current and use the greatest one.
This fixes the recent issue seen in the aarch64 builders, where
two versions of the same package were added to the transaction.
Added a new test case.
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.
While looking for dependencies, we need to check
if xbps_rpool_get_pkg() returned a suitable match;
and then validate its result.
This fixes the update_and_install test case that
was reverted via #218.
This reverts a change that solved another issue and marks the test case
for the other issue as expected failure.
The other issue is not as important as this, as it blocks updating a lot
of systems.
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
See the new test case for details, but this simulates
the recent glvnd switch, with mesa, nvidia and libglvnd.
Thanks @st3r4g for the fix! this indeed fixes the new test case.
Close#186
