This reverts commit fc95ff7881.
Unfortunately GITHUB_TOKEN authentication cannot start other action
(recent automatic update pushes haven't been built), so switch back to
a new personal access token (generated by me).
Ref: https://stackoverflow.com/a/67551255
Previously we were outputting built debs into ./debs instead of
standard folder ./output. We were also sorting built_packages.txt so
that $(cat ./built_packages.txt) returned an alphabetically sorted
list.
This caused issues for pushes that updated both a package and one or
more of its dependencies, if the dependencies start with a letter that
is later in the alphabet.
Latest example was libforestdb and libsnappy. Libforestdb depends on
libsnappy, but the buildorder as given to build-package.sh was
"libforestdb libsnappy". During the libforestdb build libsnappy was
built first, but the deb put into the standard ./output folder (that's
how our build system currently handles built dependency debs). When
build-package.sh then later tries building libsnappy it skips it
since it has already been built. We then end up with only libforestdb
in the ./debs folder.
Fix this issue by putting all debs in ./output/, and then moving the
once mentioned in built_packages.txt to ./debs/.
Fixes https://github.com/termux/termux-packages/issues/8773.
It is one (soon two) years behind, and is a big hack: some of the debs
are larger than our upload system can handle, and the file lists are
generated from the tlpdb in a not so nice way that breaks horribly on
every texlive release. Disk space is somewhat of a concern again on
the host that fosshost gives us at no (!) cost, and removing
texlive-full gives us ~1 GB of space.
The reasonable thing to do would be to set up a separate
"termux-texlive" repo, and create a package for every texlive package
rather than for every collection as done here. Debian, ubuntu and
friends properly creates subpackages. I am not really motivated to do
this though, so if someone else has use of a properly packaged texlive
and wants to look into it, then that would be great.
Users that want to use texlive should install texlive-installer
instead, it anyways allows for more convenient installation (you can
freely choose which scheme and which packages to install).
