While checking for orphans in automatic mode (xbps-query -O,
xbps-remove -o) there's no need to generate a fulldeptree...
instead we need to iterate against pkgdb until no more orphans
are found.
See https://github.com/void-linux/xbps/issues/156#issuecomment-578473222
Also add some debugging that helped me to catch the issue
easily.
Closes#156
Added support to download all dependencies even
if the euid does not have write perms to rootdir.
In this mode we only care if cachedir is writable,
rootdir access is not necessary.
This is really useful to download all binary packages
required by any number of packages as any regular
user to later perform off-line installations, i.e:
```
$ xbps-install -c $PWD/cachedir -yD xbps
...
$ tree cachedir
cachedir/
├── acl-2.2.53_1.x86_64-musl.xbps
├── acl-2.2.53_1.x86_64-musl.xbps.sig
├── attr-2.4.48_1.x86_64-musl.xbps
├── attr-2.4.48_1.x86_64-musl.xbps.sig
├── bzip2-1.0.8_1.x86_64-musl.xbps
├── bzip2-1.0.8_1.x86_64-musl.xbps.sig
├── ca-certificates-20190110_1.noarch.xbps
├── ca-certificates-20190110_1.noarch.xbps.sig
├── libarchive-3.4.1_1.x86_64-musl.xbps
├── libarchive-3.4.1_1.x86_64-musl.xbps.sig
├── libcrypto45-3.0.2_2.x86_64-musl.xbps
├── libcrypto45-3.0.2_2.x86_64-musl.xbps.sig
├── liblz4-1.9.2_1.x86_64-musl.xbps
├── liblz4-1.9.2_1.x86_64-musl.xbps.sig
├── liblzma-5.2.4_2.x86_64-musl.xbps
├── liblzma-5.2.4_2.x86_64-musl.xbps.sig
├── libressl-3.0.2_2.x86_64-musl.xbps
├── libressl-3.0.2_2.x86_64-musl.xbps.sig
├── libssl47-3.0.2_2.x86_64-musl.xbps
├── libssl47-3.0.2_2.x86_64-musl.xbps.sig
├── libtls19-3.0.2_2.x86_64-musl.xbps
├── libtls19-3.0.2_2.x86_64-musl.xbps.sig
├── libxbps-0.57.1_8.x86_64-musl.xbps
├── libxbps-0.57.1_8.x86_64-musl.xbps.sig
├── libzstd-1.4.4_1.x86_64-musl.xbps
├── libzstd-1.4.4_1.x86_64-musl.xbps.sig
├── musl-1.1.24_1.x86_64-musl.xbps
├── musl-1.1.24_1.x86_64-musl.xbps.sig
├── run-parts-4.9.1_1.x86_64-musl.xbps
├── run-parts-4.9.1_1.x86_64-musl.xbps.sig
├── xbps-0.57.1_8.x86_64-musl.xbps
├── xbps-0.57.1_8.x86_64-musl.xbps.sig
├── xbps-triggers-0.113_3.noarch.xbps
├── xbps-triggers-0.113_3.noarch.xbps.sig
├── zlib-1.2.11_3.x86_64-musl.xbps
└── zlib-1.2.11_3.x86_64-musl.xbps.sig
0 directories, 36 files
$
```
Inpired by #213Closes#213
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
If all packages in transaction are on hold, there's no
need to check for conflicts, shlibs, etc.
This makes `xbps-install -un` work faster on my system:
~0.450ms -> ~0.250ms
There's still room for more improvements :-)
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
We do not want to continue processing more threads
if pthread_create(3) fails, rather return an error.
This is for #182 but not yet fixed, there might be a
memleak somewhere.
xbps-rindex(1) has a -r option that sets the remove mode,
due to the changes added to sign repodata we need to access
to the correct directory where repository public keys are
stored. This makes the code use `$PWD/keys` before falling
back to `metadir`.
Fixes the test suite to run with unprivileged users (non root).
In the edge case when an updated package has different (or no)
alternatives groups, make sure to prune those that are in pkgdb
but not in the newly installed package.
A potentially common case of this is when a package that formerly
had alternatives gets removed and a transitional metapackage
takes its place (which has no alternatives).
When the new package has no dependencies, oldest next possible
alternatives group will be used. This is because that indicates
a removed package. When there are dependencies, the newest one
will be used; as this indicates a transitional package.
This only changes the debug messages, because modified files and conf
files are handled the same on removal and unless a conf file changes
the file type it is never deleted.
`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.
fetch/http.c:1475: warning: function might return no value: 'parse_index'
The code uses abort() before returning anything; return a proper
return value instead.
This reverts commit 08aa44602f.
The element still has to be processed and ignored by one of the
threads, it is not the last entry this will make the actually last item
be ignored.
the first thread to finish will start again from 0 (`reserved`) until
0+slicecount, next thread will then start from the end of the previous
thread which is already wrong, resulting in processing the first
slicecount*maxthreads entries twice.
The first slicecount*maxthreads entries are accounted by the thread
creation loop and `reserved` has to start at the first unaccounted index.
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
On some systems, something like this happens:
package_unpack.c:375:11: error: 'buf' may be used uninitialized in this function
This is not actually a bug as logically `buf` is always initialized
in that place, but gcc doesn't like it anyway.
