, который в итоге раскрывается в список, в ктором фигурирует libstdc++ какой-то версии... можно ли что-то сделать, чтобы libstdc++ не требовалась после раскрытия макроса?
Она включается туда автоматом, потому что по мнению debhelper нужна там. Очевидно, можно заменить этот макрос на список под свою ответственность и проверить в чистом chroot окружении без крестов и libstdc++.
ну то есть единственный способ это скопипастить список у сформированного пакета и вставить туда вручную? т.е. нету утилит или синтаксиса который бы позволил выпилить зависимость на определенную либу?
Точно не знаю, но думаю, что нет. А кроме того, думаю, что если эта либа прописана, то она реально нужна. Впрочем, это можно проверить в чистом chroot-окружении (только убедиться, что debootstrap не ставит её в это окружение автоматом).
ну на самом деле либа то нужна, просто в системе версия ниже, а менять ее нельзя, поэтому я нужную просто кладу в отдельный каталог и там ее цепляю... ну и нужно чтобы в зависимостях не требовалась эта новая либа как deb-пакет
Т. е. реально требуемой версии в системе нет, а есть более старая, но debhelper настаивает на новой? Если так, то, наверно, проще всего прописать вручную, но потом тщательно проверить, что всё работает как надо.
Однако я бы ещё спросил на debian-форуме. Может есть какой-то более красивый способ.
просто пакет мой собирался там, где есть новая... а теперь надо изворачиваться, и ставить этот пакет там, где только старая, ничего не меняя... вот как то так
Тогда надо собрать его или на этой системе, или в chroot-окружении на той системе со старой версией libstdc++ и других пакетов, зависящих от версии libstdc++. А если не пересобирать, то и зависимости не изменятся.
решил что достаточно будет подложить новую либу и изменить к ней либо rpath либо LD_LIBRARY_PATH
Для этого есть бакпорты. Если программа написана с использованием новых возможностей, и ей нужна новая либа, то новую либу надо бакпортировать (или найти готовый бакпорт). Либо пересобрать программу со старой либой. Если соберётся, то всё Ok (хотя, конечно, её ещё и протестировать со старой либой желательно). А если нет, то править программу. А как иначе? Либо ты пользуешься только старыми возможностями, и твоя программа совместима с более старыми версиями библиотек, либо нет. А пакетный менеджер помогает эти зависимости автоматически отслеживать. Можно, конечно, собрать прогу из исходников ./configure && make && make install, руками записать новую либу и прописать нужные пути. Но это прямой путь к непонятным багам и к засиранию системы файлами, которые потом сложно будет удалить, т. к. разбросаны они будут по разным каталогам, а пакетный менеджер ничего о них знать не будет. Поэтому лучше так не делать.
ну в нашем случае гемор: есть наш софт, который активно использует c++11 и c++14, и его нужно запускать на debian wheezy, где libstdc++ не умеет толком даже c++11, еще и с требованиям не менять никакие системные либы, так что...
есть наш софт, который активно использует c++11 и c++14, и его нужно запускать на debian wheezy, где libstdc++ не умеет толком даже c++11, еще и с требованиям не менять никакие системные либы
Имхо, миссия невыполнима.
Как варианты, можно либо переписать софт (скорее всего это неприемлемо), либо запускать его из chroot-окружения, где поставить свои версии либ. Можно ещё попробовать собрать статически, чтоб не зависеть от либ, но тогда софт, во-первых, страшно раздуется, а во-вторых, если он проприетарный, то статически линковать его с копилефтными либами нельзя.
Но лучше всего поинтересоваться у заказчика, почему нельзя менять системные либы. Возможно, это просто дурь или перестраховка на всякий случай. Тогда попробовать переубедить заказчика.
Ну и ещё можно извращаться, создавая альтернативные пакеты с новми либами (и с новым названием пакета) и завязывая софт на эти пакеты. Или вообще отказаться от пакетов и ставить всё руками. Но эти варианты, имхо, самые плохие.
А, для вояк, и всё сертифицировано. Тогда понятно, почему менять нельзя. Но для них и писать надо было на сертифицированных древних версиях. Хотя сейчас уже чего об этом говорить.
с rpath и подкладкой либ то вроде пока прокатило
Прокатило — и хорошо. Хотя формально, думаю, вы не правы, т. к. поставили несертифицированные либы. Поэтому копать глубже и делать по-человечески без острой на то необходимости наверно не стоит, чтоб не привлекать к этим нехорошим несертифицированным фактам лишнего внимания.
Если не хочется долго перекомпилировать, то достаточно распаковать deb, удалить нежелательную зависимость из файла control, запаковать. Так я уже правил кое-какие пакеты.
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
а во-вторых, если он проприетарный, то статически линковать его с копилефтными либами нельзя.
С LGPL можно. Нужно только предоставить объектники (*.o) проприетарного софта.
Вот этого не знал. Спасибо за инфу. А если ещё и пруф кинешь на такую статическую линковку с lgpl, чтоб до конца быть уверенным в том, что так можно, тогда двукратное спасибо.
Если не хочется долго перекомпилировать, то достаточно распаковать deb, удалить нежелательную зависимость из файла control, запаковать. Так я уже правил кое-какие пакеты.
Там неявная зависимость, вставляемая автоматически.
А если лень даже так делать, то можно создать пакет-пустышку с именем той зависимости. И всё.
Имхо, костыль и в целом очень плохая идея, которая может привести к конфликтам на пустом месте и к устанавливающимся, но реально не работающим пакетам. И ищи потом, через несколько месяцев, в чём проблема, когда программа ругается на отсутствие библиотеки, а пакетный менеджер утверждает, что она установлена. Тогда уж лучше сразу из сырцов собирать. Всё равно и так, и так загаживать систему, но в случае со сборкой из сырцов в /local/bin/ это делается хотя бы открыто, а в случае с фейковыми пакетами проблема скрывается от пользователя.