уровне системы против распространения пакета на уровне приложений

Question

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

• application-level package management (например Rubygems, если это написано в Ruby,; EasyInstall если Python, и т.д.), или
• systems-level package management (например, MacPorts для Mac, пакеты Debian для Debian, и т.д.).

NB. Если вы считаете, что в целом нет правильной практики, а скорее существуют особые обстоятельства, при которых один или другой подход явно лучше, то каковы эти обстоятельства?

Answer 1

Мне кажется, что процедура в случае приложений, пользователи довольны тем, как они распределены, примерно следующим образом:

Возьмем, к примеру:

• Bundler: написан на Ruby и полезен для разработчиков Ruby; распределенных через пакет прикладного уровня.
• fwknop: написан на Perl (первоначально, по крайней мере) и полезен конечным пользователям; распределенных через пакеты/инсталляторы системного уровня.
• Pandoc: написан в Haskell и может быть полезен разработчикам Haskell в процессе разработки приложений Haskell, но также полезен для других; распространенный какvia application-level and via systems-level packages.

Есть, вероятно, лучшие примеры, чем эти. Кроме того, мои выводы до сих пор являются лишь наблюдательными: я не нашел ссылки, в которых явным образом излагал этот поток решений. Поэтому я хотел бы получить более полный ответ.

NB. Код для блок-схемы - online, если вы хотите его адаптировать для ответа. Чтобы иметь возможность использовать его, вам понадобится рабочая установка LaTeX.

Answer 2

Согласно this blog entry, основные причины, вы должны

NEVER установить модуль Python для всей системы с Setuptools/ez_setup в системе Debian

являются

1. , что у вас могут быть разные версии одного и того же Pyt ходовых модулей на разных путях установки (устанавливается через easy_install и aptitude)

2. easy_uninstall. (Тем не менее, pip кажется, чтобы быть в состоянии сделать это: How do I remove packages installed with Python's easy_install?)

То же самое относится и к инструменту CLI, который также является модуль (Python) сортов.

Конечно, упаковка для easy_install требует меньше работы, чем упаковка для всех менеджеров системных пакетов. Но почему вы не упаковываете свой инструмент с помощью easy_install и не спрашиваете кого-нибудь, кто знаком с упаковкой для конкретных целей? (Для Debian вы можете отправить сообщение по электронной почте на адрес submit@bugs.debian.org с темой, которая начинается с «[needs-packaging]».)

Позвольте мне рассказать только о своем ограниченном опыте работы с пользователем - Python и Debian/Ubuntu , Когда я, наконец, переключился с Windows на Ubuntu, одной из основных причин была безболезненная установка почти всего программного обеспечения , которое было упаковано для Debian. Один из вопросов, в течение первого переходного периода были:

«? Что самый последний многоходовой инструмент просмотра различий в порядке, есть сливаться и диффузный Давайте посмотрим ...».

sudo apt-get install meld diffuse 

«OK. И этот менеджер буфера обмена был назван Parcellite?

sudo apt-get install parcellite 

«Мне нравится Тренер задач. У них есть это?"

sudo apt-get install taskcoach 

„Теперь, почему svn не установлена ​​из коробки?“

sudo apt-get install svn 
... (some error) 
apt-file search svn 
... (tl;dr) 
apt-file search svn | grep /svn$ 
sudo apt-get install subversion 

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