Сегодня читал про то, как Debian везде перешел на 64-х битный time_t. Изменение войдет в релиз Debian 13 (будет выпущен летом/осенью следующего года).

Проблема очень важная, ведь в 2038 году 32-х битный time_t переполнится, и многие компьютеры по всему миру не смогут узнать правильное время! А учитывая, что до 2038 года осталось немногим более 13 лет (осталось всего-то пережить пару эпидемий, восстание машин и ядерную войну), то проблему надо как-то решать!

Конечно же, не все настолько драматично. Большинство процессоров в мире уже давно как 64-х битные, и юзают «правильный», 64-х битный time_t по умолчанию почти везде. Но старые, 32-х битные системы все еще существуют, и для них надо что-то придумать.

Итак, для решения проблемы 2038 года в Debian приняли ряд компромиссных решений странных костылей. Следите внимательно, чтобы не запутаться :)
* Для 64-х битных систем time_t уже и так 64-х битный, поэтому весь «переход» заключается лишь в переименовании пакетов (например, libcurl4 → libcurl4t64). Новые пакеты с t64 при этом «предоставляют» пакет со старым именем, чтобы сторонние программы не заметили поломки ABI, не получили неудовлетворенных зависмостей и продолжали себе спокойно работать.
* Для i386 (так в Debian называют 32-х битные Intel'ы) пакеты тоже получили суффикс t64, но time_t там так и остался 32-х битным 🐳🐳 Как и на 64-х битных архитектурах, новые пакеты с t64 «предоставляют» старые. Так сделано, потому что либы под i386 очень уж часто юзаются для запуска старых программ, которые невозможно перекомпилить, поэтому поломка ABI для них нежелательна. А суффикс t64 все равно приписали, видимо, потому что переименование пакетов сделали для всех архитектур сразу.
* Для других 32-х битных архитектур (armel, armhf) пакеты тоже получили t64 суффикс, но при этом они получили еще и 64-х битный time_t.

Кстати, в Ubuntu этот переход тоже проделали, и пакеты с суффиксом t64 уже есть в последнем LTS-релизе, 24.04.

Выводы из всей этой истории делайте сами.