Steps to take to reduce repository size

[thunder-coding]

From #7491 (comment), we are using 52% of disk space. This discussion is created so that packages which need some action can be identified and he worked upon.

The disk usage can be minimised by doing certain tasks like:

1. Disabling duplicate packages

2. Adding common shared files for packages to a subpackage and declare the subpackage architecture independent. This can be done especially for shared libraries. If you want an example take fish, most of the size of the package is due to $PREFIX/share . This requires some more discussion on how it can be implemented since subpackages can depend on parent package but not vice versa

3. Disabling unused packages, i.e. packages which are less used and not so useful

[ghost]

true. disabling unnecessary packages could be done if no one used it or depending how usable package is

for duplicate packages, it should replace the one with the improved package like
squashfs-tools replaced as squashfs-tools-ng
and the improved package must be replaced from the originally requested package to reduce disk space but a cost of user experience (eg. a user may not get used to that package)

although it may be a difficult decision that removing some most unused packages could have used by some users

[thunder-coding]

Yeah, I agree to the fact that not all users can be happy with a single thing. Even though it does the same work. Also compiling packages isn't a cup of tea, especially for a platform as unique as Termux which isn't plain Android neither completely Linux compactible.

I think what Termux needs is a community maintained repository which can have lot more packages than what we have now.

[ghost]

yeah, also for requesting a package or opening a PR. i would advise to think twice whether the package is "usable" by everyone instead of just for you. it may be usable to you but not be usable for everyone and just wastes repo disk space

and whether you compiled it for termux, still think twice. reasons include because it compiled successfully for termux we should add it or because i can and i want to isn't a reason for having a new package and can be rejected sometimes. should explain how usable is and how fully-featured the package and how useful for everyone

users can host their own PPA-like repositories like github pages and @its-pointless' repo. not only they can be used for them but also for everyone

[ghost]

although it may be a difficult decision that removing some most unused packages could have used by some users

Currently all packages have their users. However some packages are downloaded 1000+ times per day and some are about 20 times per month.

[thunder-coding]

germanium vs silicon

Both do the same work of generating image from source code

[ghost]

Most of duplicate packages are small. But cumulatively each of them adds their cents to inactive packages which eventually become just disk space waste.

Currently no actions for freeing disk space will be taken - I don't know whether Fornwall's plans of making custom F-Droid repo for serving in-APK packages for termux/termux-app#1072 will be realized. If not, then we are free to use all remaining space with leaving small amount for system purposes. Otherwise something will had to be cut. This can be a repository with .deb files (hitting users preferring apt) or newer repo with in-APK packages (and thus reducing even more A10-compatible Termux functionality).

So please when submitting package request issue or pull request with build scripts. always think about Packaging Policy. It intends to notify contributor that our resources ARE FINITE as well as some things could be inappropriate for packaging for other reasons.

If some package is very needed for you specifically, then build it yourself. But if you think this package will be useful for community, you can request it to be officially packaged. Also we encourage creating own repositories - this helps community to grow and be less dependent on our resources.

[ghost]

Adding common shared files for packages to a subpackage and declare the subpackage architecture independent.

This can be done, but currently we aren't in situation with critically low disk space. Making package dependency relationships even more complex is potentially unwanted.

This can be done especially for shared libraries. If you want an example take fish, most of the size of the package is due to $PREFIX/share

For arch independent things like docs and other data files, but not for shared libraries. Also don't forget that things in $PREFIX/share may contain hardcoded architecture specific configuration.

subpackages can depend on parent package but not vice versa

This is not true. Parent package can depend on sub package. This is what qemu-system-x86-64-headless do, it depends on sub package qemu-common.

[Harshiv-Patel]

Why not just make a list of 20-30 biggest debs from the built repo & try to cull their sizes?
Any package below 200KB deb size probably won't make a significant difference unless you have 10-20 different versions/duplicates of it in the repo.

[nikey02]

I think we should filter and remove the packages that are
Installable using package manager like . npm pip cargo ... Which are present in repo now also which does need any patches

• rust is big one can't we separate docs which takes much space
• openjdk packages can be removed i mean we can directly install from their respective site like gradle, Kotlin etc

[laurentlbm]

I think we should filter and remove the packages that are Installable using package manager like . npm pip cargo ...

I disagree about cargo. Those packages are binaries that don't require the runtime to also be installed. Rust takes a lot of space on a device and building a binary through cargo on can take quite a long time on a slow device.