Как построить список зависимостей для пакета deb
Я хочу упаковать мое приложение qt в deb. В ходе исследования зависимостей с ldd я получил ~ 50 библиотек. Полный список ниже:
libgstreamer-plugins-base0.10-0,
libgstreamer0.10-0,
libglib2.0-0,
libasound2,
liboss4-salsa-asound2,
libssl1.0.0,
libx11-xcb1,
libxi6,
libxcb-render-util0,
libsm6,
libice6
libxcb1,
libxcb-glx0,
libxcb-render0,
libxcb-image0,
libxcb-icccm4,
libxcb-sync1,
libxcb-xfixes0,
libxcb-shm0,
libxcb-randr0,
libxcb-shape0,
libxcb-keysyms1,
libxcb-xkb1,
libxcb-dri2-0,
libxcb-present0,
libfontconfig1,
libfreetype6,
libxrender1,
libx11-6,
libjpeg-turbo8,
libpng12-0,
zlib1g,
libglib2.0-0,
libgl1-mesa-glx,
libstdc++6,
libgcc1,
libc6,
liborc-0.4-0,
libglib2.0-0,
libxml2,
libffi6,
libxext6,
libuuid1,
libxau6,
libxdmcp6,
libxcb-util0,
libexpat1,
libpcre3,
libglapi-mesa,
libxdamage1,
libxfixes3,
libxshmfence1,
libxxf86vm1,
libdrm2,
liblzma5
Я хочу минимизировать этот список, исходя из предположения, что в этом списке есть зависимость между какой-то библиотекой и друг другом.
Мои вопросы:
- Какой инструмент поможет мне свести к минимуму?
- Какие зависимости из списка выше предварительно установлены для Ubuntu?
1 ответ
я хочу минимизировать этот список, на основе предположения, что существует зависимость между некоторым lib и друг другом в этом списке.
Вы не должны делать этого. Список зависимостей должен включать каждую библиотеку, от которой непосредственно зависит Ваше программное обеспечение. Причина этого состоит в том, что Ваш двоичный файл требует что библиотека, и точно что библиотека, для соединения правильно, когда выполнено. Предположим, что Вы пытаетесь оптимизировать это:
- Ваша программа зависит от libX, и libY
- libY зависит от libX
- , Таким образом, Вы пытаетесь минимизировать это путем определения зависимости только к libY
Теперь, что происходит, если специалист по обслуживанию автора или пакета libY изменяет их код, чтобы больше не зависеть от libX? Ваш пакет повредится. Это повреждается, потому что Вы сделали ложное предположение - что libY будет всегда зависеть от libX. То предположение не допустимо - зависимости пакетов могут и действительно изменяться со временем. Таким образом, если для Вашей программы нужен libX, необходимо определить это.
хорошие новости - то, что список общих библиотек может быть сгенерирован автоматически с помощью dpkg-shlibdeps:
8.6.1 от общих библиотек
, Когда пакет, который содержит любые общие библиотеки или скомпилированные двоичные файлы, создается, он должен выполнить dpkg-shlibdeps на каждой общей библиотеке и скомпилировал двоичный файл для определения пользовавшихся библиотек и следовательно зависимости, необходимые пакету. [66], Чтобы сделать это, поместите вызов в dpkg-shlibdeps в Ваш debian/rules файл в исходном пакете. Перечислите все скомпилированные двоичные файлы, библиотеки или загружаемые модули в Вашем пакете. [67] dpkg-shlibdeps будет использовать символы или shlibs файлы, установленные общими библиотеками для генерации информации о зависимостях. Пакет должен тогда обеспечить подставляемую переменную, в которую может быть помещена обнаруженная информация о зависимостях.
при создании udeb для использования в Установщике Debian необходимо будет определить, что dpkg-shlibdeps должен использовать строку зависимости типа udeb путем добавления-tudeb опции [68]. Если не будет никакой строки зависимости типа udeb в shlibs файле, то dpkg-shlibdeps отступит к регулярной строке зависимости.
dpkg-shlibdeps помещает информацию о зависимостях в debian/substvars файл по умолчанию, который тогда используется dpkg-gencontrol. Необходимо будет поместить $ {shlibs:Depends} переменная в поле Depends в файле управления каждого двоичного пакета, созданного этим исходным пакетом, который содержит скомпилированные двоичные файлы, библиотеки или загружаемые модули. Если у Вас будет несколько двоичных пакетов, необходимо будет назвать dpkg-shlibdeps на каждом, который содержит скомпилированные библиотеки или двоичные файлы. Например, Вы могли использовать-T опцию для dpkg утилит для определения различного substvars файла для каждого двоичного пакета. [69]
для получения дополнительной информации на dpkg-shlibdeps, см. dpkg-shlibdeps (1).
Мы говорим, что двоичное нечто непосредственно пользуется библиотекой libbar, если оно явно связано с той библиотекой (то есть, библиотека перечислена в ELF НЕОБХОДИМЫЙ атрибут, вызванный путем добавления-lbar к строке ссылки, когда двоичный файл создается). Другие библиотеки, которые необходимы libbar, связаны косвенно с нечто, и динамический компоновщик загрузит их автоматически, когда это загрузит libbar. Пакет должен зависеть от библиотек, которыми он непосредственно пользуется, но не библиотеки, которыми он только пользуется косвенно. Зависимости для библиотек, пользовавшихся непосредственно, автоматически вытянут в косвенно используемых библиотеках. dpkg-shlibdeps обработает эту логику автоматически, но специалисты по обслуживанию пакета должны знать об этом различии между непосредственно и косвенно пользоваться библиотекой, если они должны переопределить ее результаты по некоторым причинам. [70]