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

Я настроил Предохранитель ZFS на debian/lenny для моего домашнего NAS. Я не встретился ни с какими проблемами или ограничениями. Поиск ZFS на моем блоге еще для некоторых связанных сообщений.

Я действительно попробовал BTRFS сначала, но нашел, что это просто еще не было готово. Это было в феврале 2010.

10
06.02.2018, 03:13
6 ответов

Еще один ответ, но один я считаю самым важным (просто мое собственное личное мнение), хотя другие - все хорошие ответы также.

Упаковка lib отдельно позволяет lib быть обновленным без потребности обновить приложение. Скажите, что существует ошибка в lib вместо просто способности обновить lib, необходимо было бы обновить целое приложение. Что означает, что для Вашего приложения был бы нужен удар версии без его кода, даже изменявшего, только из-за lib.

5
27.01.2020, 20:00
  • 1
    Это - важный момент, и это - часть того, почему многим дистрибутивам не нравится связывать библиотеки программами; например, Debian имеет политику не связывания библиотеки с исполняемым файлом или статически соединением библиотеки, если он никогда не может только использоваться той конкретной программой (или, для статического подключения, те случаи, где динамическое подключение не поддерживается). –  Gilles 'SO- stop being evil' 16.06.2011, 10:52
  • 2
    В конце это - возможно, наиболее важный момент. Я соглашаюсь с другими ответами также, но я должен был выбрать всего один. :) –  VPeric 26.06.2011, 14:12

Вдобавок к преимуществам Вы упомянули (безопасность, упаковка, функции), я могу думать о еще немного:

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

  • В случае этого являющегося полезным для других проектов, это уменьшило бы размер использования диска в целом (например, только одна копия кода).

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

  • Увеличение числа пользователей библиотеки (если бы это откололось) помогло бы сделать это более универсальным, который, вероятно, улучшится, это - качество также.

6
27.01.2020, 20:00
  • 1
    Все положительные стороны. Я предполагаю, что это могло быть считано как "соответствование требованиям завтрашнего дня": немногие Ваши точки в настоящее время применяются (mpmath, используется только в паре других проектов в данный момент), но легко видеть, что каждая из Ваших точек получает значение для каждого нового проекта с помощью mpmath. –  VPeric 15.06.2011, 23:12

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

Вот еще некоторые аргументы против связывания:

  • В Linux это - задание специалиста по обслуживанию распределения, чтобы гарантировать, что Ваша библиотека работает хорошо со своими зависимостями. Большинство пользователей в любом случае загрузит библиотеку с помощью диспетчера пакетов распределения. Те, кто использует соединительную линию обычно, не будут возражать проводить время при конфигурировании библиотеки так или иначе.

  • В Windows и Mac OS, диспетчеры пакетов Python как зернышко обычно используются так или иначе, начиная с установки библиотек вручную является громоздким.

  • Даже были аргументы о твердом развертывании на механизме приложения Google, но не все веб-платформы работает на нем. Многие даже требуют портирования, дисковое пространство для библиотек ограничено, и это - веб-приложение, размещающее, в конце концов! Это маловероятно для веб-приложения использовать символьную математику.

  • Никто не препятствует тому, чтобы Вы отобразили чистые сообщения об ошибках, если зависимость не доступна или имеет неверную версию.

  • Люди часто ненавидят его, когда программа считает себя более умным, чем они. Позвольте пользователям заботиться о своей собственной системе.

4
27.01.2020, 20:00
  • 1
    Можете Вы объяснять последнюю идею. Я не могу сказать, является ли это аргумент в пользу связывания. –  tshepang 15.06.2011, 23:04
  • 2
    я понимаю это по сравнению со связыванием - пользователи, хочет установить то, что они хотят, не сделали, чтобы я вызвал конкретную версию на них. –  VPeric 15.06.2011, 23:08

Надлежащий способ обработать несвязанный в пакете установщика Windows состоял бы в том, чтобы иметь тест preinst для существования библиотеки, и если это не присутствует, чтобы предложить устанавливать его от пакета библиотеки, который Вы включаете в пакет установщика программного обеспечения. Я вполне уверен большинство приложений GTK, которые имеют порты окон, делают что-то вдоль этих строк - я знаю, что гибридный язык делает.

3
27.01.2020, 20:00

Один размер не должен соответствовать всем.

Для исходных дистрибутивов, если Вы связываетесь, поставщики программного блока на многих дистрибутивах (по крайней мере, наследий Debian и Fedora) должны будут сделать дополнительную работу, чтобы отключить или удалить связывание, поскольку политики пакета для тех платформ запрещают или по крайней мере сильно препятствуют связыванию. Поэтому путем связывания Вас создают больше работы для Вашего нисходящего потока с очень небольшим преимуществом. Тот аргумент мог бы иметь некоторый вес?

Двоичные дистрибутивы (при обеспечении их) могли бы пойти так или иначе; связывание, вероятно, имеет смысл для тех, поскольку они не используются нисходящим потоком.

Но нет никакой причины, почему Вы не можете принять противоположное решение и пакет для установщиков Mac и Windows.

3
27.01.2020, 20:00
  • 1
    В то время как я соглашаюсь в целом, это действительно создает дополнительную нагрузку (однако маленький), который означает, что, вероятно, никто не поддержал бы это решение. –  VPeric 23.06.2011, 10:34

Связывание по сравнению с зависимостью является старыми дебатами в упаковочном мире. Этот документ говорит об этих двух философских школах: http://www.aosabook.org/en/packaging.html

2
27.01.2020, 20:00
  • 1
    Это было интересным чтением, но оно говорит больше о деталях реализации и различных специфических особенностях Python, чем общая философия. –  VPeric 30.06.2011, 10:36

Теги

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