LINUX.ORG.RU

исключить зависимость из макросов debhelper

 , ,


1

4

здравствуйте, есть кусок debian/control

Depends: ${misc:Depends}
, который в итоге раскрывается в список, в ктором фигурирует libstdc++ какой-то версии... можно ли что-то сделать, чтобы libstdc++ не требовалась после раскрытия макроса?

Она включается туда автоматом, потому что по мнению debhelper нужна там. Очевидно, можно заменить этот макрос на список под свою ответственность и проверить в чистом chroot окружении без крестов и libstdc++.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

ну то есть единственный способ это скопипастить список у сформированного пакета и вставить туда вручную? т.е. нету утилит или синтаксиса который бы позволил выпилить зависимость на определенную либу?

xperious ★★ ()
Ответ на: комментарий от xperious

Точно не знаю, но думаю, что нет. А кроме того, думаю, что если эта либа прописана, то она реально нужна. Впрочем, это можно проверить в чистом chroot-окружении (только убедиться, что debootstrap не ставит её в это окружение автоматом).

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

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

xperious ★★ ()
Ответ на: комментарий от xperious

Т. е. реально требуемой версии в системе нет, а есть более старая, но debhelper настаивает на новой? Если так, то, наверно, проще всего прописать вручную, но потом тщательно проверить, что всё работает как надо.

Однако я бы ещё спросил на debian-форуме. Может есть какой-то более красивый способ.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

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

xperious ★★ ()
Ответ на: комментарий от xperious

Тогда надо собрать его или на этой системе, или в chroot-окружении на той системе со старой версией libstdc++ и других пакетов, зависящих от версии libstdc++. А если не пересобирать, то и зависимости не изменятся.

aureliano15 ★★ ()
Ответ на: комментарий от xperious

То есть ты хочешь использовать фичи нового C++, но при этом зависеть только от старого рантайма? Попахивает костылём и потенциальными проблемами.

KivApple ★★★★★ ()
Ответ на: комментарий от xperious

решил что достаточно будет подложить новую либу и изменить к ней либо rpath либо LD_LIBRARY_PATH

Для этого есть бакпорты. Если программа написана с использованием новых возможностей, и ей нужна новая либа, то новую либу надо бакпортировать (или найти готовый бакпорт). Либо пересобрать программу со старой либой. Если соберётся, то всё Ok (хотя, конечно, её ещё и протестировать со старой либой желательно). А если нет, то править программу. А как иначе? Либо ты пользуешься только старыми возможностями, и твоя программа совместима с более старыми версиями библиотек, либо нет. А пакетный менеджер помогает эти зависимости автоматически отслеживать. Можно, конечно, собрать прогу из исходников ./configure && make && make install, руками записать новую либу и прописать нужные пути. Но это прямой путь к непонятным багам и к засиранию системы файлами, которые потом сложно будет удалить, т. к. разбросаны они будут по разным каталогам, а пакетный менеджер ничего о них знать не будет. Поэтому лучше так не делать.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

ну в нашем случае гемор: есть наш софт, который активно использует c++11 и c++14, и его нужно запускать на debian wheezy, где libstdc++ не умеет толком даже c++11, еще и с требованиям не менять никакие системные либы, так что...

xperious ★★ ()
Ответ на: комментарий от xperious

есть наш софт, который активно использует c++11 и c++14, и его нужно запускать на debian wheezy, где libstdc++ не умеет толком даже c++11, еще и с требованиям не менять никакие системные либы

Имхо, миссия невыполнима.

Как варианты, можно либо переписать софт (скорее всего это неприемлемо), либо запускать его из chroot-окружения, где поставить свои версии либ. Можно ещё попробовать собрать статически, чтоб не зависеть от либ, но тогда софт, во-первых, страшно раздуется, а во-вторых, если он проприетарный, то статически линковать его с копилефтными либами нельзя.

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

Ну и ещё можно извращаться, создавая альтернативные пакеты с новми либами (и с новым названием пакета) и завязывая софт на эти пакеты. Или вообще отказаться от пакетов и ставить всё руками. Но эти варианты, имхо, самые плохие.

aureliano15 ★★ ()
Ответ на: комментарий от xperious

платформа просто astra linux...

А, для вояк, и всё сертифицировано. Тогда понятно, почему менять нельзя. Но для них и писать надо было на сертифицированных древних версиях. Хотя сейчас уже чего об этом говорить.

с rpath и подкладкой либ то вроде пока прокатило

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

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

ну плюсы тоже есть: я про rpath узнал, и узнал, что по-дефолту rpath на runpath менялся)

xperious ★★ ()
Ответ на: комментарий от i-rinat

так много еще других зависимостей, которые тащат libstdc++, если их все пересобирать с таким флагом, то можно совсем чирикнуться

xperious ★★ ()
Ответ на: комментарий от aureliano15

а во-вторых, если он проприетарный, то статически линковать его с копилефтными либами нельзя.

С LGPL можно. Нужно только предоставить объектники (*.o) проприетарного софта.

gag ★★★★★ ()
Ответ на: комментарий от xperious

Если не хочется долго перекомпилировать, то достаточно распаковать deb, удалить нежелательную зависимость из файла control, запаковать. Так я уже правил кое-какие пакеты.

По мотивам https://unix.stackexchange.com/questions/138188/easily-unpack-deb-edit-postin...

mkdir tmp
cd tmp
ar p ../package.deb control.tar.xz | tar -xJ
# edit / fix
cp -ai ../package.deb ../package.deb.bak
tar cJf control.tar.xz *[!z]
ar r ../package.deb control.tar.xz

gag ★★★★★ ()
Ответ на: комментарий от gag

А если лень даже так делать, то можно создать пакет-пустышку с именем той зависимости. И всё.

gag ★★★★★ ()
Ответ на: комментарий от gag

а во-вторых, если он проприетарный, то статически линковать его с копилефтными либами нельзя.

С LGPL можно. Нужно только предоставить объектники (*.o) проприетарного софта.

Вот этого не знал. Спасибо за инфу. А если ещё и пруф кинешь на такую статическую линковку с lgpl, чтоб до конца быть уверенным в том, что так можно, тогда двукратное спасибо.

Если не хочется долго перекомпилировать, то достаточно распаковать deb, удалить нежелательную зависимость из файла control, запаковать. Так я уже правил кое-какие пакеты.

Там неявная зависимость, вставляемая автоматически.

А если лень даже так делать, то можно создать пакет-пустышку с именем той зависимости. И всё.

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

aureliano15 ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.