Рекомендации по упаковке для сторонних зависимостей
Я упаковываю приложение в первый раз для Ubuntu. У меня есть несколько зависимостей, основными из которых являются Qt и ICU. Я просто не понимаю, как развернуть эти приложения, не вдаваясь в dll-hell для Linux.
Например, я хотел бы использовать версию 4.7.4 Qt, потому что есть некоторые исправления ошибок в этом выпуске, который я хотел бы использовать. Я также хотел бы развернуть мое приложение на всех поддерживаемых версиях Ubuntu, которое возвращает меня в Lucid. Но последняя версия, доступная для Lucid, - 4.6.2, которая даже не совместима с API с 4.7.4. Параметры, как я вижу:
- Просто скажите «жестко» и поддерживайте только версии Ubuntu, у которых есть библиотека, в которой я нуждаюсь, что означало бы Oneiric на данный момент. Для более ранних версий они сами могут найти библиотеку 4.7.4 и решить все ее зависимости.
- Предоставьте частные версии библиотеки, скажем, libQtCore4_mycompany и пакет для их установки.
- Прикрепите личную версию сборки бок о бок с моим приложением (возможно,
/opt/company/package/lib) и установитеLD_LIBRARY_PATHперед выполнением моего приложения.
Ничто из этого не замечательно варианты, и, в частности, debuild ужасно использовать, если вы уходите в малейшей степени из своих ожиданий. Я не могу связать статически из-за ограничений LGPL (по крайней мере, так я их понимаю).
У меня также есть обратный вопрос. Предположим, я решил установить зависимость от libQtCore4 (>= 4.7.4). Я видел достаточно регрессий между версиями Qt, что есть вероятность, что 4.7.5, или 4.8.0, что-то сломает в моем приложении. Это то, с чем вам приходится иметь дело, или лучше всего зависеть от точной версии библиотеки, например libQtCore4 (= 4.7.4)?
1 ответ
Если вы действительно хотите поддерживать релизы, которые не имеют требуемой версии библиотеки, просто используйте статические ссылки. Имея совместно используемую библиотеку, вы являетесь единственным пользователем сбоев в работе с разделяемыми библиотеками, поэтому вы можете просто поместить все это в один двоичный файл. Вы даже сохраните некоторое пространство, так как части библиотеки, которую вы не вызываете, будут выбрасываться.
Я бы предположил, что вы начинаете с одноричной сборки, которая просто отображает зависимость обычно, а затем переключается на статическую связывание, когда вы передаете его в старые версии.
-
1Я должен был добавить к исходному вопросу: я не могу (юридически) статическую ссылку, из-за ограничений LGPL на Qt. – Dave 5 October 2011 в 20:50
-
2@Dave, ты уверен? Я думал, что LGPL указала, что ссылка в целом разрешена, а не только динамическая компоновка? Если это так, то я думаю, вам придется пойти на частную сборку общей библиотеки. – psusi 5 October 2011 в 23:06
-
3Да, лицензия запуталась. Существует предложение, которое требует, чтобы другие могли заменить версию библиотеки, которую вы используете, с той, которую они сами построили. Многие (хотя, разумеется, не единодушны) заключают, что это исключает статическое связывание, поскольку они не могут сделать это, не перестраивая ваш код. – Dave 6 October 2011 в 01:54
-
4@Dave, или вы можете сделать так, как это делают ребята видеодрайверов; предоставить ваш код как скомпилированный объектный файл, чтобы люди могли статически связать его с самой библиотекой (если они хотят использовать другую версию библиотеки). – psusi 7 October 2011 в 04:53
-
5LGPL позволяет устанавливать статические ссылки, но для этого требуется, чтобы вы предоставили объектные файлы, чтобы пользователь мог связать их с более новой версией библиотеки. – Grumbel 16 November 2011 в 23:56