Что приводит к несовместимости пакетов и двоичных файлов?
Для PDF-файлов можно использовать PDF Studio Viewer. Он может просматривать и размечать PDF-файлы с помощью различных аннотаций, таких как текст, разметка, фигуры и т. д. А диалоговое окно расширенного поиска может отображать все вхождения строки в документе.
Несовместимость двоичных файлов и пакетов — это разные вещи, и их стоит объяснить отдельно.
Двоичная несовместимость
Это то, что обычно имеют в виду, когда люди говорят о различиях цепочек инструментов и т. д. Несовместимости цепочек инструментов сами по себе необычны, потому что цепочки инструментов, наряду с ядром,одна из областей, где разработчики наиболее тщательно следят за сохранением обратной совместимости. В результате двоичный файл, созданный в прошлом, должен продолжать работать до тех пор, пока его двоичные зависимости остаются доступными; это сводится к сохранению необходимых библиотек.
Что-то не так с прямой совместимостью :Нельзя гарантировать, что двоичный файл, созданный «в будущем», будет работать. Обычно это проявляется в виде отсутствующих символов в библиотеке C (, которые обнаруживаются именно потому, что разработчики библиотеки C уделяют большое внимание поддержанию совместимости ). Можно подумать, что библиотека C не сильно меняется, поэтому создание программы с использованием разных библиотек C не должно менять нужные ей символы, и она должна оставаться совместимой. Это не так, и функции регулярно меняются обратно -несовместимыми способами; библиотека C сохраняет обратную совместимость, продолжая предоставлять версии функций, совместимые с предыдущими интерфейсами, с соответствующим символом версии. Например, версия 2.33 библиотеки GNU C имеет несовместимые изменения таких общих функций, как семейство stat(fstat/lstat/statи т. д. ); программа, созданная с настройкой по умолчанию 2.33, использующая эти функции, потребует для запуска версии 2.33 библиотеки C.
Связанные с Toolchain -библиотеки и библиотека C поддерживаются таким образом, что такие несовместимости проявляются как изменения символов библиотек или изменений soname и, таким образом, в конечном итоге кодируются в зависимостях пакетов (для упакованного программного обеспечения )или перехватываются динамическим компоновщиком (для отдельных двоичных файлов ).
В библиотеках, которые не так тщательно поддерживаются, как библиотека C, такие несовместимости проявляются не сразу, они обнаруживаются только при проверке ошибочной комбинации (, да и то, возможно, только при определенных обстоятельствах ).Разработчики дистрибутива обычно тестируют пакеты только в контексте разрабатываемого выпуска, поэтому они не будут знать, что пакет, который они создали для Ubuntu 20.04, правильно устанавливается в Debian 10, но убивает вашу любимую белку, если вы используете его между 1:00 и 2:00 CEST июня. 21.
Это прекрасно ведет к...
Несовместимость пакетов
Делается это сознательно или нет, пакеты редко создаются в вакууме, они являются частью дистрибутива. Это начинается с исходного кода пакета (и, в более общем смысле, самого исходного кода проекта ):проекты и пакеты создаются в системах их разработчиков, и, если не прилагать к этому больших усилий, они могут неточно кодировать свои зависимости.
Это сводится к зависимостям бинарных пакетов и зависимостям, описанным в документации. Сопровождающий проекта может не осознавать, что его проект в текущей конфигурации работает только потому, что, скажем, systemd версии 239 начал определенным образом настраивать систему. Сопровождающие пакеты также могут этого не осознавать, если выпуск дистрибутива, над которым они работают, уже имеет версию 239 systemd (, имейте в виду, что сопровождающие дистрибутива обычно живут в будущем, т.е. они разработать в следующем выпуске ).
Все это можно обнаружить при тестировании, но как только вы начнете смешивать и сопоставлять бинарные файлы из разных дистрибутивов и выпусков, вы, вероятно, станете первым, кто протестирует точную комбинацию пакета и бинарного файла. версии. И что поэтому это не рекомендуется :большинство пользователей хотят использовать свои системы, а не тестировать их.
Конечно, и это соответствует вашему опыту, во многих случаях все просто работает. Это также способствует предвзятости, которую вы воспринимаете :люди, как правило, не пишут сообщения (или вопросы,в контексте Stack Exchange ), объясняя, как они установили пакет X из дистрибутива Y в свою систему Z, и это просто сработало. Таким образом, большая часть контента, который вы видите в этой области, представляет собой сценарии, в которых что-то не работало , или оказалось сложным в настройке, или сломало что-то еще; и люди по понятным причинам неохотно тратят время на помощь кому-то в устранении, возможно, разовой -проблемы, которую они навлекли на себя, сделав что-то, что было явно рекомендовано против .