Продолжая тему совместим ли двоичный файл Ubuntu LTS с Debian?

Я знаю, что бинарные пакеты Ubuntu и Debian чаще всего несовместимы. Я знаю, что смешивание пакетов из разных источников, как правило, плохая идея, и людей постоянно предостерегают от этого. Так что давайте оставим дискуссию чисто технической...

Что именно внесет несовместимость для пакетов из разных источников, когда, конечно, проблемы не в зависимостях?

------ Разделение, подробнее ниже ------

Например, поговорка:

о бинарной совместимости (https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): Пакеты Debian, скорее всего, созданы с разными версиями цепочки инструментов, поэтому у вас могут возникнуть проблемы

Почему разные версии набора инструментов могут вызвать проблемы? Нравится

  • Я знаю, как загрузить минимальный набор пакетов из Debian sid в свою стабильную версию Debian, и делал это все время,
  • Раньше я переносил пакеты из старых версий Ubuntu/Debian в их новые версии или даже
  • копирование одного исполняемого файла из моего Ubuntu / Debian в другой дистрибутив, будь то RedHat или даже FreeBSD,

И никогда раньше не было проблем. Так что же именно вызывает проблему, о которой говорят люди?

Это версия gcc или ядра? Для меня это маловероятно, так как они постоянно обновляются на протяжении всей моей жизни, используя этот выпуск.

Так это версия glibc? Но это будет обратно совместимо, как правило, и, скорее всего, верно?

Цитата из ответа по моей первой ссылке:

На самом деле нет никакой гарантии или даже намека на кросс-совместимость. Не ожидайте, что сообщества Debian или Ubuntu окажут вам большое сочувствие, если что-то пойдет не так. В этом случае вы в основном сами по себе. Пока вас это устраивает, не стесняйтесь попробовать.

Так что в основном я везде вижу предостережения против практики, но никто не дает дополнительных технических объяснений. Может ли кто-нибудь перечислить риски, связанные с этим, эти потенциальные технические проблемы, пожалуйста?

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

0
xpt 11 Июн 2021 в 01:30
1
Вы действительно должны сократить свой вопрос, хотя я не уверен, почему вы вообще задаете вопрос, вы, очевидно, нашли более чем достаточно доказательств, чтобы ответить на него. А вот попытаться понять - другое дело. Помните, что это бесплатное программное обеспечение, для определенного пакета вы можете загрузить исходный код и пересобрать двоичный файл в целевом дистрибутиве с собственными библиотеками, таким образом преодолевая проблемы binary compatibility. И да, вам действительно может сойти с рук смешивание двоичных файлов. Однако удачи, если что-то пойдет не так.
 – 
Eduardo Trápani
11 Июн 2021 в 01:18
Спасибо за ответ, но сборка из исходного кода для меня не вариант, так как это означает, что я потеряю все преимущества установки бинарных пакетов из дистрибутивов/PPA. Что касается сокращения вопроса, я считаю, что, поскольку людям не нравятся детали, просто прочитайте первые два абзаца; а для людей, которые настаивают на том, чтобы я делал домашнее задание, прежде чем спрашивать, или, говоря более конкретно, они могут прочитать остальное. Я действительно не могу удовлетворить оба мира одновременно.
 – 
xpt
11 Июн 2021 в 01:33
Честно говоря, я очень удивлен вашим заявлением о том, что вы взяли бинарный файл из Ubuntu/Debian и запустили его на FreeBSD. Был ли это статический или динамический исполняемый файл?
 – 
fpmurphy
11 Июн 2021 в 07:35
Установка бинарных пакетов из другого дистрибутива не выгодна. Именно лень неизбежно приведет к катастрофе (или, по крайней мере, к беспорядку). В самых простых случаях, то есть в пакетах без зависимостей, содержащих только файлы данных или простые сценарии оболочки, это, вероятно, будет работать (для некоторых ограниченных определений «работы»). Во всех остальных случаях вы играете с надежностью и стабильностью вашей системы. Есть очень веские причины, по которым так много людей и веб-сайтов советуют вам не делать этого. Послушайте их — скачайте пакеты с исходниками, пересоберите под свою систему.
 – 
cas
11 Июн 2021 в 08:15
"В самых простых случаях, то есть в пакетах без зависимостей, содержащих только файлы данных или простые сценарии оболочки, это, вероятно, сработает", как указано в моем OP, как вы думаете, вытащить emacs из Ubuntu PPA в Debian будет работать @cas? Мой ответ может вас удивить. Вот почему я сказал, давайте сохраним обсуждение чисто техническим (и не будем просто пытаться отпугнуть людей расплывчатыми утверждениями).
 – 
xpt
12 Июн 2021 в 05:13

1 ответ

Лучший ответ

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

Бинарная несовместимость

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

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

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

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

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

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

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

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

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

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

4
Stephen Kitt 11 Июн 2021 в 10:45