Change the way Termux packages are updated #19616
-
|
The vulnerability discovered with liblzma led to me to realize how bleeding edge termux is. Is there another update channel for Termux which is more stable? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 11 replies
-
|
No. Termux has only one update channel. |
Beta Was this translation helpful? Give feedback.
-
|
Since there is only one update channel, should the packages be updated as frequently as they currently are? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. We update packages as soon as possible and if there are no porting problems. |
Beta Was this translation helpful? Give feedback.
-
|
Termux officially only provides one channel and uses a rolling release model. We do not have enough maintainers to resolve issues with compatibility with multiple versions of dependencies. Moreover, our server also has limited space, so we cannot keep multiple versions/channels, although cost of space is not an issue these days like it used to be a few years ago when we were relying on donated servers. Lot of users want latest features provided by softwares, so we generally update packages whenever upstream releases an update. Having a |
Beta Was this translation helpful? Give feedback.
-
Actuqlly when github will release aarch64 runner we may try to write some termux-rootfs runtime consistency check to ensure that if we update some library all reverse-dependencies can be started and run self-checks (or special tests we can write or package tests provided by packages). So we will be sure package update does not brake basic stuff. |
Beta Was this translation helpful? Give feedback.
-
Unless backports are done like linux distros do, which we don't have resources for. We actually do not even have the time to review every package to see if there are bug or security fixes in newer versions, let alone do backports for them.
Yeah, such testing is of course planned, but currently not done. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that most package upgrades are necessarily unattended, my question is more: If version 2.3.1 of some package is currently available in Termux and the upstream maintainer releases 2.3.2 and 2.4.0, which version should be chosen? To me the former would be less likely to result in manual intervention, while the latter is likely to introduce new features that may interact in unknown ways. I don't see a compelling reason that liblzma needed to be upgraded in February from the discussion and links shared here. Nor do I see how upgrading less often would necessitate back ports or increase maintenance costs. I'm suggesting that minor package upgrades are released on a more as-needed basis rather than being pushed directly from upstream. |
Beta Was this translation helpful? Give feedback.
-
If 2.4.0 version of package does not break compatibility with other packages (it is critical in the case if it is a library) and there are no porting problems we will choose 2.4.0. |
Beta Was this translation helpful? Give feedback.
-
As twaik said, we would likely go with
That is just the risk of a rolling release model. Check unstable/testing channels for debian.
How do you suppose we find compelling reason for whether a package should be upgraded or not? That would require looking at changelogs and commits and possibly related issues/pulls of the changes to decide if its worth it. Not all packages would strictly follow semantic versioning design for changes. We do not have the resources to check for such changes for updates of every package.
Of course it would require us to work on backports if we cannot upgrade to latest version, just as debian distro does it, as upstreams don't always provide backports themselves, and its only done if they have some LTS release design themselves...
That wouldn't necessarily protect from malicious code, it could just as easily have been added to a major upgrade too and not found out as it was very obfuscated. |
Beta Was this translation helpful? Give feedback.
Termux officially only provides one channel and uses a rolling release model. We do not have enough maintainers to resolve issues with compatibility with multiple versions of dependencies. Moreover, our server also has limited space, so we cannot keep multiple versions/channels, although cost of space is not an issue these days like it used to be a few years ago when we were relying on donated servers.
Lot of users want latest features provided by softwares, so we generally update packages whenever upstream releases an update.
Having a
stablewhile possible, would require more maintenance effort.