> Открою страшную тайну, AUR source-based, у него нет разделения по архитектурам. Звон который вы слышали это образы с разными целевыми архитектурами, они не не имеют отношения к архитектуре хоста, и конечно же никакие отдельные репы под них никто не делает. Также как, например, под кросс-компиляторы в разные цели.Открою страшную тайну -- сабж (repology) считает source-пакеты. И обычно никто не делает отдельный сорс-пакет под каждую целевую архитектуру:
https://packages.debian.org/sid/gcc-arm-linux-gnueabi
https://packages.debian.org/sid/gcc-arm-linux-gnueabihf
https://packages.debian.org/sid/gcc-mips-linux-gnu
https://packages.debian.org/sid/gcc-i686-linux-gnu
У всех общий сорс:
[gcc-defaults_1.180.tar.gz]
И считается (для дебиана) только он - gcc-arm-linux-gnueabi и прочие в реположи отсутствуют, зато куча отдельных вариантов из AURа:
arm-linux-gnueabi-gcc∗ 8.2.0 1 8.2.0
arm-linux-gnueabihf-gcc∗ 8.1.0 1
arm-linux-gnueabihf-gcc-linaro∗ 7.3 1
arm-linux-gnueabihf-gcc-stage1∗ 8.1.0 1
arm-linux-gnueabihf-gcc-stage2∗ 8.1.0 1
arm-none-eabi-gcc47-linaro∗ 4.7_2014.06 1
arm-none-eabi-gcc47-linaro-alternative∗ 4.7_2014.06 1
...
Еще?
packages.debian.org/stretch/google-android-platform-16-installer
...
packages.debian.org/stretch/google-android-platform-19-installer
packages.debian.org/stretch/google-android-platform-21-installer
packages.debian.org/stretch/google-android-platform-20-installer
...
packages.debian.org/stretch/google-android-platform-23-installer
сорс у всех один:
http://deb.debian.org/debian/pool/contrib/g/google-android-i...
И в сабже это идет как один пакет для Debian:
https://repology.org/metapackage/google-android-installers/v...
А вот для AUR -- угадайте с одного раза (подсказка: 16 уникальных сорс-пакетов) :)
android-platform∗ 28_r06 1
android-platform-13∗ 3.2_r01 1
android-platform-14∗ 4.0.2_r04 1
android-platform-15∗ 4.0.4_r05 1
android-platform-16∗ 4.1.2_r05 1
android-platform-17
...
>> Еще одна тайна: старые версии пакетов обычно хранят в старых версиях реп :)
> И опять мимо, есть случаи когда старые версии пакетов нужны для современного
> софта (например, устаревший python27 до сих под много чему нужен, и ещё долго будет доступен в актуальных репозиториях).
Вы путаете теплое с мягким, старые версии пакетов != старое ПО:
https://packages.debian.org/source/stretch/python2.7 (2.7.13-2+deb9u3)
https://packages.debian.org/source/sid/python2.7 (2.7.15-4)
И давайте обойдемся без развешивания макаронных изделий -- современный софт, зависящий от _фиксированной версии_ чего-то, скорее всего притянет это что-то с собой, в качестве 3rd party. Тупо потому что иначе у автора будут пилить в багтрекере. Если автор забъет, то этим займется мейнтейнер пакета. Иначе такой софт в актуальной системе не будет нормально собираться.
Но в реальности, поиск и "колупание" старых версий пакетов обычно нужно для сборки не менее заброшенного софта, т.е. легаси.
Которое обычно тянет другое легаси и плохо дружит с современными версиями ПО (не говоря уже о том, что установка старых, неподдерживаемых (а значит и непропатченых) версий софта чревата кучей дыр и результирующий "сюрпризов").
Поэтому такой софт с тем же успехом можно сразу взять из старой репы и/или собрать в отдельном окружении.
