Недавно я узнал, как легко получить исходный код любого пакета с помощью apt-get source
, чтобы я мог получить исходный код, внести изменения и установить свою собственную модифицированную версию любого пакета. Это здорово!
До сегодняшнего дня я предполагал, что каждый пакет будет иметь свой собственный исходный код, и что разные пакеты будут иметь разные исходные коды.
Однако теперь я обнаружил, что разные пакеты могут иметь идентичный исходный код. Вот пример этого:
Следующие 4 пакета, похоже, имеют идентичный исходный код:
gir1.2-mutter-4
libmutter-4-0
mutter
mutter-common
Все четыре пакета установлены на моем компьютере Ubuntu 19.04. Выполнение команды apt-get source gir1.2-mutter-4
дает точно такой же результат, как и apt-get source libmutter-4-0
, а также для пакетов mutter
и mutter-common
.
Вот как я проверил это:
mkdir a
cd a
apt-get source gir1.2-mutter-4
cd ..
mkdir b
cd b
apt-get source libmutter-4-0
cd ..
diff -r a b
Рекурсивный diff в последней строке выше не дает никакого результата, показывая, что каталоги имеют идентичное содержимое.
Теперь к моему вопросу: **Как разные пакеты могут иметь идентичный исходный код?
Если предположить, что так и было задумано, а не какая-то ошибка, в чем разница между пакетами и как я могу увидеть эту разницу?
Может ли быть так, что пакеты отличаются способом конфигурирования и компиляции исходного кода, например, разные части кода включены в разные пакеты? Если да, то где я могу найти информацию о том, как настроить каждый пакет?
Edit: забыл добавить, что если вы хотите проверить это, то для того, чтобы apt-get source
работал должным образом, вам может потребоваться сначала включить его с помощью software-properties-gtk
, как описано здесь: https://askubuntu.com/a/857433/874649.
Edit 2: спасибо за отличные ответы! Я также нашел это полезное https://askubuntu.com/a/246721/874649 - о командах apt-get build-dep
и dpkg-buildpackage
, которые очень полезны. После изменения исходного кода исходного пакета, команда dpkg-buildpackage -us -uc
может быть использована для создания нового .deb файла(ов), который может быть использован для установки измененной программы(ов).
Вы путаете собранные бинарные пакеты с базовым исходным кодом/пакетом, из которого были собраны пакеты.
Все пакеты, на которые вы ссылаетесь, собраны из одного исходного кода/пакета mutter
. Вы можете легко найти это, зайдя на packages.ubuntu.com
, найти пакет, который вы'ищете, а затем обратиться к "Исходному пакету", на который он ссылается. В данном случае это mutter
:
Оттуда, однако, мы можем проверить страницу Launchpad для исходного пакета Mutter' и увидеть, что она собирает множество бинарных пакетов (собранный скомпилированный исходный код и т.д. для установки):
Эти описания описывают, что содержит/устанавливает каждый пакет. Сосредоточьтесь на 4 указанных вами пакетах и используйте эти описания:
gir1.2-mutter-4
- данные интроспекции GObject для Mutter (используется gir
и GObject как библиотеки/данные для взаимодействия Mutter и GObject)libmutter-4-0
- базовая библиотека для оконного менеджера Mutter. (Обычно используется для разработки плагинов, разработки и компиляции интеграций Mutter и т.д.)mutter
- собственно оконный менеджер Mutter, использующий GNOME's Window Manager Library (именно поэтому необходим GObject)mutter-common
- общие файлы для Mutter - обычно параметры конфигурации по умолчанию или элементы, которые являются общими для всех пакетов, собранных из исходного пакета.То, что вы видите в списке пакетов - это сборка пакетов, которые происходят из одного и того же исходного кода - каждый пакет - это различные элементы, устанавливаемые после сборки/компиляции и используемые для разных вещей. Вы можете увидеть, что содержится в самих пакетах, скачав отдельные пакеты, а затем получив доступ к ним с помощью p7zip или встроенного менеджера архивов в Ubuntu, и увидеть различия в том, что содержит каждый пакет. При этом все они происходят из одного и того же исходного кода - они просто содержат разные элементы, которые устанавливаются в систему.
Исходные пакеты и бинарные пакеты существуют отдельно. Каждый исходный пакет может иметь несколько двоичных пакетов, связанных с ним. Это означает, что из одного исходного пакета может быть собрано более одного двоичного пакета.
Один из распространенных способов, как это происходит: у вас есть программа, библиотека, которую программа использует для выполнения большей части своей работы, и заголовочные файлы, используемые для компиляции этой программы и других (возможно, будущих) программ, использующих эту библиотеку. Все они разрабатываются и поддерживаются в одном дереве исходных текстов, которое используется, с исправлениями Debian или Ubuntu или без них, для создания пакета исходных текстов. Затем этот исходный пакет используется для создания отдельных бинарных пакетов для программы, библиотеки и заголовков.
Это то, что вы имеете здесь (с некоторыми другими двоичными пакетами также). Вы указали разные двоичные пакеты в команде apt source
, но команда загружает и распаковывает один и тот же исходный пакет.
Это происходит потому, что, когда вы передаете команде apt source
имя пакета a, но исходного пакета с таким именем не существует, она воспринимает его как имя бинарного пакета и предполагает, что вам нужен соответствующий исходный пакет.
На главной странице Ubuntu на Launchpad вы можете искать пакеты. Launchpad отображает информацию об исходных пакетах (в то время как Ubuntu Packages Search отображает информацию о бинарных пакетах). Если вы ищете mutter
, то как сказал Томас Уорд вы найдете страницу Launchpad для исходного пакета mutter
в Ubuntu. Это один из хороших способов узнать, какие бинарные пакеты соответствуют исходному пакету. В верхней части этой страницы говорится:
пакет mutter в Ubuntu
gir1.2-mutter-4: данные интроспекции GObject для Mutter libmutter-4-0: библиотека оконного менеджера от оконного менеджера Mutter libmutter-4-0-dbgsym: Нет доступной информации для libmutter-4-0-dbgsym в ubuntu eoan.
libmutter-4-dev: файлы разработки для оконного менеджера Mutter mutter: Пример оконного менеджера, использующего библиотеку оконного менеджера GNOME'. mutter-common: общие файлы для оконного менеджера Mutter mutter-dbgsym: отладочные символы для mutter
Даже если бинарный пакет не имеет того же имени, что и исходный пакет, из которого он собран, вы обычно можете найти этот исходный пакет, выполнив поиск бинарного пакета на Launchpad.
Часто можно узнать о связи между бинарным пакетом и исходным пакетом, использованным для его сборки, посмотрев на имя бинарного пакета:
Имена бинарных пакетов, начинающиеся с lib
, обычно предоставляют библиотеки кода, которые могут использоваться множеством программ (включая будущие программы).
Те, которые заканчиваются на -dev
, предоставляют заголовочные файлы, которые облегчают компиляцию исходного кода, использующего библиотеки.
Те, которые заканчиваются на -dbg
или -dbgsym
, предоставляют отладочные символы (поэтому, даже если libmutter-4-0-dbgsym
в настоящее время не показывает сводку, мы знаем, что это пакет отладочных символов).
Те, которые заканчиваются на -common
, обычно предоставляют файлы, часто файлы данных, которые находятся в /usr/share
. Такие файлы иногда эффективно представляют собой код, только в статической и декларативной форме, но они также могут обеспечивать перевод интерфейса на естественные (т.е. человеческие) языки. На самом деле нет особых ограничений на то, что может входить в такой пакет.
Для mutter
бинарный пакет -common
(в последних версиях) содержит схемы, привязки ключей и документацию. Одним из преимуществ пакетов -common
является то, что, поскольку они обычно не содержат собственного машинного кода, один и тот же пакетный файл обычно применим ко всем архитектурам. (Строго говоря, это единственное ключевое требование для файлов, размещенных в /usr/share
).
Возьмите следующие ингредиенты:
Можете ли вы приготовить из них только одно блюдо? Нет. То, что вы в итоге съедите, зависит от рецепта.
Каждый пакет содержит рецепт. Он указывает компьютеру, что нужно сделать с ингредиентами, чтобы получить желаемое блюдо (блюда).
Это разумно и нормально, что некоторые пакеты имеют общий список ингредиентов. Конечно, в данном контексте вы ожидаете, что на практике так будет только в том случае, если эти пакеты происходят из одного проекта.