Что приводит к несовместимости пакетов/двоичных файлов?

Question

Несовместимость двоичных файлов и пакетов различна и заслуживает отдельного объяснения.

Двоичная несовместимость

Это обычно то, что имеется в виду, когда люди говорят о различиях в цепочках инструментов и т.п.Цепочка инструментовнесовместимости сами по себе необычны, поскольку toolchain, наряду с ядром, является одной из областей, где разработчики наиболее осторожны в сохранении обратной совместимости. В результате, двоичный файл, собранный в прошлом, должен продолжать работать, пока егодвоичныйзависимости по-прежнему доступны; это сводится к сохранению необходимых библиотек.

Где все ломается, так это с совместимостью вперед: нельзя гарантировать, что двоичный файл, созданный «в будущем», будет работать. Обычно это проявляется в виде отсутствующих символов в библиотеке C (которые обнаруживаются именно потому, что разработчики библиотеки C очень заботятся о поддержании совместимости). Можно подумать, что библиотека C не сильно меняется, поэтому сборка программы с другими библиотеками C не должна менять нужные ей символы, и она должна оставаться совместимой. Это не так, и функции регулярно изменяются обратно несовместимыми способами; библиотека C сохраняетназадсовместимость , продолжая предоставлять версии функций, совместимые с предыдущими интерфейсами, с соответствующим символом версии. Например, версия 2.33 библиотеки GNU C имеет несовместимые изменения в таких общих функциях, как семейство stat( fstat// и т.д.); программа, созданная с настройкой по умолчанию 2.33, использующая эти функции, потребует для запуска версии 2.33 библиотеки C.lstatstat

Библиотеки, связанные с цепочкой инструментов, и библиотека C поддерживаются таким образом, что такие несовместимости проявляются в виде изменений символов библиотеки или изменений soname и, таким образом, кодируются в зависимостях пакетов (для упакованного программного обеспечения) или обнаруживаются динамическим компоновщиком (для отдельных двоичных файлов).

В библиотеках, которые не так тщательно поддерживаются, как библиотека C, такие несовместимости не проявляются сразу, они проявляются только в случае тестирования неисправной комбинации (и даже тогда, возможно, только при определенных обстоятельствах). Разработчики дистрибутивов обычно тестируют пакеты только в контексте разрабатываемого релиза, поэтому они не будут знать, что пакет, который они собрали для Ubuntu 20.04, правильно устанавливается на Debian 10, но убьет вашу белку, если вы используете его между 1 и 2 часами ночи по центральноевропейскому летнему времени 21 июня.

Это плавно приводит к ...

Несовместимость пакетов

Независимо от того, делается ли это сознательно или нет, пакеты редко создаются в вакууме, они являются частью выпуска дистрибутива. Это начинается с самого источника пакета (и, в более общем смысле, источника проекта): проекты и пакеты создаются на системах их разработчиков, и если не приложить больших усилий, они могут неточно кодировать свои зависимости.

Это сводится к зависимостям бинарных пакетов и зависимостям, описанным в документации. Сопровождающий проекта может не понимать, что его проект в его текущей конфигурации работает только потому, что, скажем, systemd версии 239 начал настраивать систему определенным образом. Сопровождающие пакетов могут не понимать этого также, если релиз дистрибутива, над которым они работают, уже имеет версию 239 systemd (имейте в виду, что сопровождающие дистрибутива обычно живут в будущем,то естьони получат развитие в следующем релизе).

Все этомогбыть пойманным при тестировании, но как только вы начнете смешивать и сопоставлять двоичные файлы из разных дистрибутивов и релизов, вы, вероятно, будете первым человеком, который когда-либо тестировал вашу точную комбинацию версий пакетов и двоичных файлов. ИчтоВот почему это не рекомендуется: большинство пользователей хотят использовать свои системы, а не тестировать их.

Конечно, и это соответствует вашему опыту, во многих случаях все просто работает. Это также способствует предвзятости, которую вы воспринимаете: люди, как правило, не пишут посты (или вопросы, в контексте Stack Exchange), объясняющие, как они установили пакет X из дистрибутива Y на свою систему Z, и это просто заработало. Поэтому большая часть контента, который вы видите в этой области, представляет собой сценарии, где вещине сделалработать, или его было сложно настроить, или он сломал что-то еще; и люди, как и следовало ожидать, неохотно тратят время на помощь кому-то в исправлении, вероятно, одноразовой проблемы, которую они сами себе создали, сделав что-то, что было явно рекомендованопротив.

Answer 1

Несовместимость двоичных файлов и пакетов различна и заслуживает отдельного объяснения.

Двоичная несовместимость

Это обычно то, что имеется в виду, когда люди говорят о различиях в цепочках инструментов и т.п.Цепочка инструментовнесовместимости сами по себе необычны, поскольку toolchain, наряду с ядром, является одной из областей, где разработчики наиболее осторожны в сохранении обратной совместимости. В результате, двоичный файл, собранный в прошлом, должен продолжать работать, пока егодвоичныйзависимости по-прежнему доступны; это сводится к сохранению необходимых библиотек.

Где все ломается, так это с совместимостью вперед: нельзя гарантировать, что двоичный файл, созданный «в будущем», будет работать. Обычно это проявляется в виде отсутствующих символов в библиотеке C (которые обнаруживаются именно потому, что разработчики библиотеки C очень заботятся о поддержании совместимости). Можно подумать, что библиотека C не сильно меняется, поэтому сборка программы с другими библиотеками C не должна менять нужные ей символы, и она должна оставаться совместимой. Это не так, и функции регулярно изменяются обратно несовместимыми способами; библиотека C сохраняетназадсовместимость , продолжая предоставлять версии функций, совместимые с предыдущими интерфейсами, с соответствующим символом версии. Например, версия 2.33 библиотеки GNU C имеет несовместимые изменения в таких общих функциях, как семейство stat( fstat// и т.д.); программа, созданная с настройкой по умолчанию 2.33, использующая эти функции, потребует для запуска версии 2.33 библиотеки C.lstatstat

Библиотеки, связанные с цепочкой инструментов, и библиотека C поддерживаются таким образом, что такие несовместимости проявляются в виде изменений символов библиотеки или изменений soname и, таким образом, кодируются в зависимостях пакетов (для упакованного программного обеспечения) или обнаруживаются динамическим компоновщиком (для отдельных двоичных файлов).

В библиотеках, которые не так тщательно поддерживаются, как библиотека C, такие несовместимости не проявляются сразу, они проявляются только в случае тестирования неисправной комбинации (и даже тогда, возможно, только при определенных обстоятельствах). Разработчики дистрибутивов обычно тестируют пакеты только в контексте разрабатываемого релиза, поэтому они не будут знать, что пакет, который они собрали для Ubuntu 20.04, правильно устанавливается на Debian 10, но убьет вашу белку, если вы используете его между 1 и 2 часами ночи по центральноевропейскому летнему времени 21 июня.

Это плавно приводит к ...

Несовместимость пакетов

Независимо от того, делается ли это сознательно или нет, пакеты редко создаются в вакууме, они являются частью выпуска дистрибутива. Это начинается с самого источника пакета (и, в более общем смысле, источника проекта): проекты и пакеты создаются на системах их разработчиков, и если не приложить больших усилий, они могут неточно кодировать свои зависимости.

Это сводится к зависимостям бинарных пакетов и зависимостям, описанным в документации. Сопровождающий проекта может не понимать, что его проект в его текущей конфигурации работает только потому, что, скажем, systemd версии 239 начал настраивать систему определенным образом. Сопровождающие пакетов могут не понимать этого также, если релиз дистрибутива, над которым они работают, уже имеет версию 239 systemd (имейте в виду, что сопровождающие дистрибутива обычно живут в будущем,то естьони получат развитие в следующем релизе).

Все этомогбыть пойманным при тестировании, но как только вы начнете смешивать и сопоставлять двоичные файлы из разных дистрибутивов и релизов, вы, вероятно, будете первым человеком, который когда-либо тестировал вашу точную комбинацию версий пакетов и двоичных файлов. ИчтоВот почему это не рекомендуется: большинство пользователей хотят использовать свои системы, а не тестировать их.

Конечно, и это соответствует вашему опыту, во многих случаях все просто работает. Это также способствует предвзятости, которую вы воспринимаете: люди, как правило, не пишут посты (или вопросы, в контексте Stack Exchange), объясняющие, как они установили пакет X из дистрибутива Y на свою систему Z, и это просто заработало. Поэтому большая часть контента, который вы видите в этой области, представляет собой сценарии, где вещине сделалработать, или его было сложно настроить, или он сломал что-то еще; и люди, как и следовало ожидать, неохотно тратят время на помощь кому-то в исправлении, вероятно, одноразовой проблемы, которую они сами себе создали, сделав что-то, что было явно рекомендованопротив.

Что приводит к несовместимости пакетов/двоичных файлов?

решение1

Двоичная несовместимость

Несовместимость пакетов

Связанный контент