for pkg, and apt.
apt-get differs;
apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
bash coreutils dpkg gpgv libandroid-support
libunistring rsync vim wget
0 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
Maybe related;
https://github.com/termux/termux-packages#information-for-android-7-users
re-installing the rootfs as described in the above link fixed this but that's more of a workaround. The package manager should take care if it.
apt-get upgrade
apt-get dist-upgrade as you actually not upgrading specific packages but whole distribution.
Maybe related;
https://github.com/termux/termux-packages#information-for-android-7-users
No, it isn't.
Interesting which version of libandroid-support you have.
Post output of apt show libandroid-support.
apt-get was unable to install the packages it kept back, erroring with the same as pkg, and apt.
Install/upgrade should work regardless of dist-upgrade.
A fresh rootfs fixed the issue so clearly it was related (how could replacing everything with a fresh install not be related).
I'd love to try apt-get dist-upgrade and apt show libandroid-support for you but I did not keep a copy of the old rootfs.
should work regardless of dist-upgrade.
It shouldn't.
Regular upgrade will refuse to uninstall (even temporary) and replace packages if required.
In Termux you have to upgrade distribution (consist of upgrading, removing & replacing packages - whatever is required) and not currently installed packages.
So maybe regular upgrade for apt/pkg was attempting to replace packages it should have left for full/dist-upgrade. Only apt-get knew to keep back some packages.
I have used dist-upgrade on other systems, and never have I seen regular upgrade break because full/dist-upgrade was not run. It's optional by definition. If that was the issue, i'd have to conclude termux is using package managers wrongly.
The whole point of apt update is it is supposed to be safe and never result in error. full/dist-upgrade is supposed to be the more risky operation.
I have used dist-upgrade on other systems, and never have I seen regular upgrade break
Typical Ubuntu & Debian installations will not cause such breakages. They do not use rolling-release update scheme and backwards-incompatible changes are introduced only with newer distribution version (e.g. in transition from Debian 8 to 9).
Termux is more like Arch Linux or Debian sid.
I've never had such an issue with pacman but granted I use it less.
I think the bottom lines are;
1) apt should have left the listed packages for full-upgrade instead of trying to replace them on upgrade.
2) pkg has no full/dist-upgrade option (listed in help) so should not have errored or should not be installed if it can't be made to function.
Pacman just goes stright forward and replaces everything. Unlike apt, it doesn't require additional command line utilities to work.
When packages conflict, something should be removed.
It has because it is wrapper for apt. See https://github.com/termux/termux-packages/blob/master/packages/termux-tools/pkg#L43
Output here, @xeffyr
$ apt show libandroid-support -a
Package: libandroid-support
Version: 24-3
Essential: yes
Maintainer: Fredrik Fornwall @fornwall
Installed-Size: 176 kB
Pre-Depends: dpkg (>= 1.19.4-3)
Homepage: https://github.com/termux/libandroid-support
Download-Size: 105 kB
APT-Sources: https://termux.net stable/main arm Packages
Description: Library extending the Android C library (Bionic) for additional multibyte, locale and math support
Package: libandroid-support
Version: 24
Status: install ok installed
Essential: yes
Maintainer: Fredrik Fornwall @fornwall
Installed-Size: 176 kB
Homepage: https://github.com/termux/libandroid-support
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /data/data/com.termux/files/usr/var/lib/dpkg/status
Description: Library extending the Android C library (Bionic) for additional multibyte, locale and math support
$
Edit: apt-get dist-upgrade gives the same error as apt upgrade. I'm on arm, not aarch64, so that differs:
Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential package libandroid-support:arm due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:arm (2)
I have the same problem. Transcript:
Welcome to Termux!
Wiki: https://wiki.termux.com
Community forum: https://termux.com/community
IRC channel: #termux on freenode
Gitter chat: https://gitter.im/termux/termux
Mailing list: [email protected]
Search packages: pkg search
Install a package: pkg install
Upgrade packages: pkg upgrade
Learn more: pkg help
$ pkg upgrade
Hit:1 https://termux.net stable InRelease
Ign:2 https://dl.bintray.com/grimler/game-packages-21 games InRelease
Ign:3 https://dl.bintray.com/grimler/science-packages-21 science InRelease
Get:4 https://dl.bintray.com/grimler/game-packages-21 games Release [5344 B]
Hit:4 https://dl.bintray.com/grimler/game-packages-21 games Release
Get:5 https://dl.bintray.com/grimler/science-packages-21 science Release [5348 B]
Hit:5 https://dl.bintray.com/grimler/science-packages-21 science Release
Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists... Done
Building dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency tree
Reading state informatReading state informatReading state information... Done
40 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists.Reading package lists.Reading package lists... Done
Building dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency tree
Reading state informatReading state informatReading state information... Done
Calculating upgrade...Calculating upgrade...Calculating upgrade... Done
The following NEW packages will be installed:
bzip2 coreutils
diffutils
findutils gnupg
grep gzip
libassuan libiconv
libksba libnpth
pcre pinentry sed
tar
termux-licenses
xz-utils
The following packages will be upgraded:
apt bash busybox
ca-certificates
clang
command-not-found
curl dnsutils dpkg
gdbm git gpgv krb5
ldns less
libandroid-support
libbz2 libc++
libcurl libdb
libffi libllvm
liblua liblzma
libnghttp2
libsqlite
libunistring man
ncurses
ncurses-ui-libs
netcat nodejs
openssh openssl
python readline
tcl termux-exec
termux-tools wget
40 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/55.5 MB of archives.
After this operation, 19.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential package libandroid-support:aarch64 due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:aarch64 (2)
$
Same problem here..., I fixed it by reinstall the core too. A bit of cleanup is ok after months without using it...
Same Problem Here Too..
I Fixed it by Clear Data and Update the App..
My Termux Not Updated yet..
And It Works..
The following NEW packages will be installed:
bzip2 coreutils
diffutils
findutils gnupg
grep gzip
libassuan libiconv
libksba libnpth
pcre pinentry sed
tar
termux-licenses
xz-utils
Hmm, there happens following:
Few months ago iconv() implementation was moved from libandroid-support to libiconv. But since old libandroid-support provides libiconv.so symlink used by essential utilities (like coreutils), package libiconv can't be installed.
Now busybox was replaced by separate packages which makes coreutils to be required for installation. So here a conflict loop starts to happen.
Since now we have static libraries, I can link coreutils and few other essential packages with libandroid-support statically and remove this dependency (apt should be able to temporary uninstall/deconfigure it). But if this won't solve the issue, I'm not sure if something else can be done...
Same Issue:
E: This installation run will require temporarily removing the essential package libandroid-support:arm due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:arm (2)
Fixed by removing and re-installing app, then:
pkg upgrade
Anyways, I'm still wondering about suggestion, how to activate the APT::Force-LoopBreak option ?
how to activate the APT::Force-LoopBreak option
Should be like apt -o APT::Force-LoopBreak=yes dist-upgrade.
Unfortunately, the suggested command left me without a busybox package:
$ apt -o APT::Force-LoopBreak=yes dist-upgrade
The following NEW packages will be installed:
bzip2 coreutils
diffutils
findutils gnupg
grep gzip
libassuan libiconv
libksba libnpth
pcre pinentry sed
tar
termux-licenses
xz-utils
The following packages
will be upgraded:
apt bash busybox
ca-certificates
clang
command-not-found
curl dnsutils dpkg
gdbm git gpgv krb5
ldns less
libandroid-support
libbz2 libc++
libcurl libdb
libffi libllvm
liblua liblzma
libnghttp2
libsqlite
libunistring man
ncurses
ncurses-ui-libs
netcat nodejs
openssh openssl
python readline
tcl termux-exec
termux-tools wget
40 upgraded, 17 newly
installed, 0 to remove
and 0 not upgraded.
Need to get 0 B/55.5 MB of archives.
After this operation,
19.6 MB of additional
disk space will be used.
Do you want to continu
e? [Y/n] y
9744 files and directories currently installed.)
Preparing to unpack .../libbz2_1.0.8-1_aarch64.deb ...
Unpacking libbz2 (1.0.8-1) over (1.0.6-2) ...
Setting up libbz2 (1.0.8-1) ...
Selecting previously unselected package bzip
2.
9746 files and directories currently installed.)
Preparing to unpack ..
./bzip2_1.0.8-1_aarch64.deb ...
Unpacking bzip2 (1.0.8-1) ...
Setting up bzip2 (1.0.8-1) ...
9761 files and directories currently installed.)
Preparing to unpack ..
./busybox_1.30.1-4_aarch64.deb ...
Unpacking busybox (1.30.1-4) over (1.30.1-1)
...
dpkg: warning: 'tar' not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Couldn't configure
libiconv:aarch64, probably a dependency cycle.
E: Could not perform immediate configuration
on 'coreutils:aarch64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
E: Sub-process /data/data/com.termux/files/usr/bin/dpkg returned an error code (2)
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Silas S. Brown http://people.ds.cam.ac.uk/ssb22
Unfortunately, the suggested command left me without a busybox package...
ssb22 as xeffyr has already seen in https://github.com/termux/termux-packages/issues/4128 termux is asking the package managers to do the wrong thing, so just refresh the app and move on so no one need actually fix this issue.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Silas S. Brown http://people.ds.cam.ac.uk/ssb22
so just refresh the app and move on so no one need actually fix this issue.
Maybe I miss your point but using "clear all data" is not a solution but a complete desaster because all data is getting lost. Try to suggest this solution to upgrade installed Linux-Distributions from one version to another!
termux is asking the package managers to do the wrong thing
IMHO the package manager does what it should do. Upgrades using apt-get are working for years on Debian. If the system cannot correctly upgraded with a specific version then someone released a broken version.
If the system cannot correctly upgraded with a specific version then someone released a broken version.
Debian was "well designed" from scratch and critical dependency switches were not required, unlike Termux. Debian also not rolling release but Termux it is, once incompatible changes rolled out, they are expected for installation by everyone. Those who "holding" packages for long time are on their own.
It is possible to do upgrade without issues. Just little more work required than just pkg upgrade and will include manual installation of few packages through dpkg.
Switching implementation of different critical things used by package manager can broke system, especially if old and new package provide same file and old one has to be uninstalled to install a new one. This doesn't mean that new version is broken. It just broke previous.
My answer is in two parts: Basic questions and problem solving. Let's start with the latter.
It is possible to do upgrade without issues. Just little more work required than just
pkg upgradeand will include manual installation of few packages throughdpkg.
Your suggestion above did not work. Which workaround will fix the issue?
Now to the basic questions. Firstly, I do not want to blame anyone. I just want to give some feedback to encourage reflection.
Debian also not rolling release but Termux it is, once incompatible changes rolled out, they are expected for installation by everyone. Those who "holding" packages for long time are on their own.
Every update process is a kind of rolling-release. It makes no sense to distinguish between a release "when its done" or "every 1st of July" - unless you want to say "rolling release" equals "untetest".
Updating/upgrading packages is handled by an update manager like apt. It's fault of the repository manager and package manager if the packages are not correctly rolled out. If any update is breaking the system and the latter is not recoverable then whole project is getting broken.
I didn't pin any packages, but I encountered the same problem as the error reporter. IMHO "holding" packages is something that is not part of the actual problem.
Switching implementation of different critical things used by package manager can broke system, especially if old and new package provide same file and old one has to be uninstalled to install a new one.
Please explain: Why can every serious Linux distro upgrade "apt" without any problem?
This doesn't mean that new version is broken. It just broke previous.
So you say: The system will probably be corrupted again and again by a subsequent update/upgrade? This is indeed a really serious problem for the whole project.
IMHO: If we cannot trust the update/upgrade process then the entire project is broken.
Your suggestion above did not work. Which workaround will fix the issue?
It works. But there additional arguments required for dpkg.
unless you want to say "rolling release" equals "untetest".
What I want to say is:
There no schedule of releasing global/major changes. They can be released at any time.
Changes may be backwards incompatible and tested only for ONE previous package version.
If backwards-incompatible change scheduled, it is done independently of previous one. In rare cases
backwards-incompatible changes are mutually-exclusive and replace each other.
From point 2 & 3, it should became obviously that upgrade process should work fine when your packages are at "current" version and are not outdated (say installed half-year ago).
I didn't pin any packages
Never pin packages in Termux !
It's fault of the repository manager and package manager if the packages are not correctly rolled out.
I manually rolled out updates for:
Switching iconv(), iconv_open() implementation from libandroid-support to GNU libiconv.
Replacing busybox by standalone packages.
Check git for clear information about what was done.
Please explain: Why can every serious Linux distro upgrade "apt" without any problem?
Because it doesn't use libandroid-support and busybox as absolute base replacing which can broke system.
Termux isn't serious Linux distro and basically built on hacks - the main cause of introducing updates leading to potential breakage.
So you say: The system will probably be corrupted again and again by a subsequent update/upgrade?
In case of long-time "package holding", I can say only: Termux installations which didn't upgraded for long time are not guaranteed for successful upgrade in future. If you didn't used Termux for several month, it may be easier to wipe $PREFIX and re-install packages you need.
I have same problem
I also have the same question.
Has the problem been solved?