Как различные пакеты могут иметь идентичный исходный код?

Question 1

Я недавно изучил, как легкий это должно получить исходный код для любого данного использования пакета 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

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

Теперь к моему вопросу: Как различные пакеты могут иметь идентичный исходный код?

Предположение, что это предназначается и не некоторая ошибка, каково различие между пакетами и как я могу видеть то различие?

Могло случиться так, что пакеты отличаются в способе, которым исходный код настроен и скомпилирован, например, различные части кода включены в различные пакеты? Если так, где я могу найти информацию о том, как настроить каждый пакет?

Править: забыл добавлять это, если Вы хотите протестировать это, сделать apt-get source работайте правильно, Вы, возможно, сначала должны включить ему использование software-properties-gtk как описано здесь: https://askubuntu.com/a/857433/874649

Редактирование 2: спасибо за превосходные ответы! Я также нашел этот полезный https://askubuntu.com/a/246721/874649 - о apt-get build-dep и dpkg-buildpackage команды, которые очень полезны. После изменения исходного кода для исходного пакета, dpkg-buildpackage -us -uc может использоваться для создания нового .deb файла (файлов), который может использоваться для установки измененной программы (программ).

Question 2

Вы путаете созданные двоичные пакеты с базовым исходным кодом / пакет, из которого были созданы пакеты.

Пакеты, к которым Вы обращаетесь, все создаются из того же исходного кода / пакет, mutter. Можно найти что легко путем движения в packages.ubuntu.com, поиск пакета, Вы смотрите на и затем отсылаете к "Исходному пакету" его, относится к. Который в этом случае является mutter:

Оттуда, однако, мы можем проверить страницу Launchpad на исходный пакет Бормотания и видеть, что это создает множество двоичных пакетов (созданный скомпилированный исходный код, и т.д. для установки):

Эти описания описывают то, что содержит/устанавливает каждый пакет. При фокусировке на этих 4 пакетах Вы указали, и использующий эти описания:

gir1.2-mutter-4 - Данные самоанализа GObject для Бормотания (используемый gir и GObject как библиотеки/данные для Бормотания и взаимодействия GObject)
libmutter-4-0 - Базовая библиотека для менеджера окон Бормотания. (Используемый для разработки плагинов, разработки и компилирующий интеграцию Бормотания, и т.д. обычно)
mutter - фактический Менеджер окон Бормотания, который пользуется Библиотекой Менеджера окон GNOME (который является, почему GObject необходим),
mutter-common - Совместно используемые файлы для Бормотания - обычно параметры конфигурации по умолчанию или объекты, которые характерны для всех пакетов, созданных из исходного пакета.

Что Вы видите в своем списке пакета, созданные пакеты, которые происходят из того же исходного кода - каждый пакет является различными объектами, устанавливаемыми после сборки/времени компиляции, и используется по-другому для разных вещей. Вы видите то, что находится в самих пакетах путем загрузки отдельных пакетов и затем доступа к ним с p7zip или встроенным менеджером Архива в Ubuntu, и посмотрите различия того, что каждый пакет содержит тот путь. С учетом вышесказанного, они все происходят из того же исходного кода - они просто содержат различные объекты, это устанавливается на системе.

Question 3

Question 4

Исходные пакеты и двоичные пакеты существуют отдельно. Каждый исходный пакет может иметь несколько двоичных пакетов, связанных с ним. Это должно сказать, что больше чем один двоичный пакет может быть создан из того же исходного пакета.

Один из распространенных способов, которыми это происходит, - то, что у Вас есть программа, библиотека, что использование программы, чтобы сделать большую часть ее работы и заголовочные файлы раньше компилировало ее и другой (возможно, будущее) программы, которые пользуются той библиотекой. Они все разрабатываются и сохраняются в том же исходном дереве, которое используется, с или без Debian или патчей Ubuntu, для генерации исходного пакета. Затем тот исходный пакет используется для создания отдельных двоичных пакетов для программы, библиотеки и заголовков.

Это - то, что Вы имеете здесь (с некоторыми другими двоичными пакетами также). Вы указали различные двоичные пакеты в Вашем apt source команда, но команда загружает и распаковывает тот же исходный пакет.

Это происходит, потому что при передаче имени пакета к apt source но нет никакого исходного пакета с тем именем, оно рассматривает его как название двоичного пакета и предполагает желание соответствующего исходного пакета того двоичного пакета.

На основной странице Ubuntu на Панели запуска можно искать пакеты. Панель запуска отображает информацию об исходных пакетах (пока Поиск Пакетов Ubuntu отображает информацию о двоичных пакетах). Если Вы ищете mutter, затем, поскольку Thomas Ward сказал, что Вы найдете страницу Launchpad для mutter исходный пакет в Ubuntu. Это - один хороший способ видеть, какие двоичные пакеты соответствуют исходному пакету. Около начала той страницы это говорит:

пакет бормотания в Ubuntu

gir1.2-mutter-4: данные самоанализа GObject для Бормотания
libmutter-4-0: библиотека менеджера окон из менеджера окон Бормотания
libmutter-4-0-dbgsym: Никакая сводка, доступная для libmutter-4-0-dbgsym в человечности eoan.
libmutter-4-dev: Файлы для разработчика для менеджера окон Бормотания
бормотание: менеджер окон В качестве примера, пользующийся библиотекой менеджера окон GNOME
общий для бормотания: совместно используемые файлы для менеджера окон Бормотания
бормотание-dbgsym: отладочные символы для бормотания

Даже когда двоичный пакет не имеет того же имени как исходный пакет, из которого это создается, можно обычно находить что исходный пакет путем поиска на Панели запуска двоичный пакет.

Можно часто знать то, что отношения между двоичным пакетом, и исходный пакет раньше создавал их путем осмотра названия двоичного пакета:

Двоичные имена пакета, которые запускаются с lib обычно обеспечивайте библиотеки кода, который может использоваться несколькими программами (включая будущие программы).
Те, которые заканчиваются в -dev обеспечьте заголовочные файлы, которые упрощают компиляцию исходного кода, который пользуется библиотеками.
Те, которые заканчиваются в -dbg или -dbgsym обеспечьте отладочные символы (итак даже при том, что libmutter-4-0-dbgsym в настоящее время не показывает сводку, мы знаем, что это - пакет отладочного символа).
Те, которые заканчиваются в -common будьте склонны обеспечивать файлы, часто файлы данных, которые находятся в /usr/share. Такие файлы являются иногда эффективно кодом, только в статической и декларативной форме, но они могут также обеспечить интерфейсные переводы в естественный (т.е. человек) языки. Нет действительно большого ограничения на то, что может войти в такой пакет.

Для mutter, -common двоичный пакет (в последних версиях) содержит схемы, привязки клавиш и документацию. Одно преимущество -common пакеты - то, что, потому что они обычно не содержат собственного машинного кода, тот же файл пакета, обычно относится ко всей архитектуре. (Строго говоря это - одно ключевое требование для файлов, помещенных в /usr/share.)

Question 5

Возьмите следующие компоненты:

Лук
Помидоры
Хлеб
Маслины

Можно ли только сделать одну тарелку из них? Нет. То, что Вы заканчиваете тем, что ели, зависит от рецепта.

Каждый пакет содержит рецепт. Это говорит компьютер, что сделать с компонентами, для создания требуемой тарелки (тарелок).

Это разумно и нормально для некоторых пакетов совместно использовать список компонентов. Конечно, в этом контексте, Вы ожидали бы, что только для имения место на практике, когда упомянутые пакеты происходят из того же проекта.

N0rbert · Accepted Answer · 23 November 2019 в 00:12

Вы путаете созданные двоичные пакеты с базовым исходным кодом / пакет, из которого были созданы пакеты.

Пакеты, к которым Вы обращаетесь, все создаются из того же исходного кода / пакет, mutter. Можно найти что легко путем движения в packages.ubuntu.com, поиск пакета, Вы смотрите на и затем отсылаете к "Исходному пакету" его, относится к. Который в этом случае является mutter:

Оттуда, однако, мы можем проверить страницу Launchpad на исходный пакет Бормотания и видеть, что это создает множество двоичных пакетов (созданный скомпилированный исходный код, и т.д. для установки):

Эти описания описывают то, что содержит/устанавливает каждый пакет. При фокусировке на этих 4 пакетах Вы указали, и использующий эти описания:

gir1.2-mutter-4 - Данные самоанализа GObject для Бормотания (используемый gir и GObject как библиотеки/данные для Бормотания и взаимодействия GObject)
libmutter-4-0 - Базовая библиотека для менеджера окон Бормотания. (Используемый для разработки плагинов, разработки и компилирующий интеграцию Бормотания, и т.д. обычно)
mutter - фактический Менеджер окон Бормотания, который пользуется Библиотекой Менеджера окон GNOME (который является, почему GObject необходим),
mutter-common - Совместно используемые файлы для Бормотания - обычно параметры конфигурации по умолчанию или объекты, которые характерны для всех пакетов, созданных из исходного пакета.

Что Вы видите в своем списке пакета, созданные пакеты, которые происходят из того же исходного кода - каждый пакет является различными объектами, устанавливаемыми после сборки/времени компиляции, и используется по-другому для разных вещей. Вы видите то, что находится в самих пакетах путем загрузки отдельных пакетов и затем доступа к ним с p7zip или встроенным менеджером Архива в Ubuntu, и посмотрите различия того, что каждый пакет содержит тот путь. С учетом вышесказанного, они все происходят из того же исходного кода - они просто содержат различные объекты, это устанавливается на системе.

Eliah Kagan · Answer 2 · 23 November 2019 в 00:12

Исходные пакеты и двоичные пакеты существуют отдельно. Каждый исходный пакет может иметь несколько двоичных пакетов, связанных с ним. Это должно сказать, что больше чем один двоичный пакет может быть создан из того же исходного пакета.

Один из распространенных способов, которыми это происходит, - то, что у Вас есть программа, библиотека, что использование программы, чтобы сделать большую часть ее работы и заголовочные файлы раньше компилировало ее и другой (возможно, будущее) программы, которые пользуются той библиотекой. Они все разрабатываются и сохраняются в том же исходном дереве, которое используется, с или без Debian или патчей Ubuntu, для генерации исходного пакета. Затем тот исходный пакет используется для создания отдельных двоичных пакетов для программы, библиотеки и заголовков.

Это - то, что Вы имеете здесь (с некоторыми другими двоичными пакетами также). Вы указали различные двоичные пакеты в Вашем apt source команда, но команда загружает и распаковывает тот же исходный пакет.

Это происходит, потому что при передаче имени пакета к apt source но нет никакого исходного пакета с тем именем, оно рассматривает его как название двоичного пакета и предполагает желание соответствующего исходного пакета того двоичного пакета.

На основной странице Ubuntu на Панели запуска можно искать пакеты. Панель запуска отображает информацию об исходных пакетах (пока Поиск Пакетов Ubuntu отображает информацию о двоичных пакетах). Если Вы ищете mutter, затем, поскольку Thomas Ward сказал, что Вы найдете страницу Launchpad для mutter исходный пакет в Ubuntu. Это - один хороший способ видеть, какие двоичные пакеты соответствуют исходному пакету. Около начала той страницы это говорит:

пакет бормотания в Ubuntu

gir1.2-mutter-4: данные самоанализа GObject для Бормотания
libmutter-4-0: библиотека менеджера окон из менеджера окон Бормотания
libmutter-4-0-dbgsym: Никакая сводка, доступная для libmutter-4-0-dbgsym в человечности eoan.
libmutter-4-dev: Файлы для разработчика для менеджера окон Бормотания
бормотание: менеджер окон В качестве примера, пользующийся библиотекой менеджера окон GNOME
общий для бормотания: совместно используемые файлы для менеджера окон Бормотания
бормотание-dbgsym: отладочные символы для бормотания

Даже когда двоичный пакет не имеет того же имени как исходный пакет, из которого это создается, можно обычно находить что исходный пакет путем поиска на Панели запуска двоичный пакет.

Можно часто знать то, что отношения между двоичным пакетом, и исходный пакет раньше создавал их путем осмотра названия двоичного пакета:

Двоичные имена пакета, которые запускаются с lib обычно обеспечивайте библиотеки кода, который может использоваться несколькими программами (включая будущие программы).
Те, которые заканчиваются в -dev обеспечьте заголовочные файлы, которые упрощают компиляцию исходного кода, который пользуется библиотеками.
Те, которые заканчиваются в -dbg или -dbgsym обеспечьте отладочные символы (итак даже при том, что libmutter-4-0-dbgsym в настоящее время не показывает сводку, мы знаем, что это - пакет отладочного символа).
Те, которые заканчиваются в -common будьте склонны обеспечивать файлы, часто файлы данных, которые находятся в /usr/share. Такие файлы являются иногда эффективно кодом, только в статической и декларативной форме, но они могут также обеспечить интерфейсные переводы в естественный (т.е. человек) языки. Нет действительно большого ограничения на то, что может войти в такой пакет.

Для mutter, -common двоичный пакет (в последних версиях) содержит схемы, привязки клавиш и документацию. Одно преимущество -common пакеты - то, что, потому что они обычно не содержат собственного машинного кода, тот же файл пакета, обычно относится ко всей архитектуре. (Строго говоря это - одно ключевое требование для файлов, помещенных в /usr/share.)

Lightness Races with Monica · Answer 3 · 23 November 2019 в 00:12

Возьмите следующие компоненты:

Лук
Помидоры
Хлеб
Маслины

Можно ли только сделать одну тарелку из них? Нет. То, что Вы заканчиваете тем, что ели, зависит от рецепта.

Каждый пакет содержит рецепт. Это говорит компьютер, что сделать с компонентами, для создания требуемой тарелки (тарелок).

Это разумно и нормально для некоторых пакетов совместно использовать список компонентов. Конечно, в этом контексте, Вы ожидали бы, что только для имения место на практике, когда упомянутые пакеты происходят из того же проекта.

Как различные пакеты могут иметь идентичный исходный код?

3 ответа

пакет бормотания в Ubuntu

Другие вопросы по тегам:

Похожие вопросы: