Как правильно установить файл tar.gz в Linux - как управлять установленными вручную (или автономными) приложениями?

Я вижу все эти ссылки, объясняющие пакеты и .debs ... Я знаю это ... и есть много ключей для работы файлов tar.gz (например: update-альтернативы для Java или удаление файла вручную в / usr / local / мусорное ведро (или где-то еще, что я вывел из часов поисков)). Если пакеты такие умные, как же так мало приложений Linux доступно в пакетах или .debs / rpms?

Я говорю как новый пользователь; Я знаю, что эксперты, вероятно, знают это лучше (я думаю, что могу загрузить компилируемую версию Eclipse?). Подобно netbeans и chrome .sh, eclipse - это простой, запускаемый каталог, Java требует этого, update-alternativesно я не думаю, что он регистрируется в «списке программ» Ubuntu / Debian (просто регистрируется как команда) и т. Д. (Я знаю, что это иногда доступны в репозиториях, но я просто запутался, почему страницы загрузки не имеют надлежащих объяснений).

Короче говоря: если вы скачаете или скомпилируете файл tar.gz, как мне зарегистрировать его в системе? update-alternativesкажется, регистрирует его как команду, в Ubuntu он не отображается в строке поиска. В Debian я могу вручную добавить ярлык для запуска GNOME 2. Но что я действительно должен делать?

Редактировать:

Поэтому, поиграв немного больше с новыми решениями, я могу немного улучшить свою «проблему»:

Как мне управлять моими программами, установленными вручную? Firefox и Eclipse - мои единственные примеры (я не загружаю много вещей). Они оба могут выбежать из коробки, которая мне нравится. Кроме того, где я должен их устанавливать? Я вижу, что у Eclipse есть свои собственные инструкции, но я бы предпочел делать все мои «ручные пакеты» одинаково.

1. После некоторых исследований я решил внедрить эти программы /usr/local/bin.
2. Из того, как установить eclipse , я подумал, что нужно показать что-то в панели запуска, мне нужно поместить xxx.desktopфайл в ~/.local/share/applications/. Имеет ли значение имя этого файла .desktop?
3. Вещи с автоинструментами (я ищу configureили unix/configureфайл) будет работать нормально. Некоторые исследования, которые я должен использовать, CheckInstallчтобы отслеживать все это.
4. Я должен использовать update-alternativesдля регистрации путей. Из этой ветки Java , похоже, я создаю ссылку /usr/bin/javaна /usr/lib/jvm/jdk.... Когда я устанавливаю эти "автономные" приложения, такие как Eclipse или Firefox, я должен всегда ссылаться на /usr/bin/[app]? И если утверждение 1 верно, я бы делал такие вещи, какsudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Являются ли эти инструкции правильными / хорошим способом управления установками вручную? Есть ли какие-то другие шаги, которым я должен следовать? Другие предложения?

Почему многие приложения не доступны в репозиториях?

Там может быть много причин:

• Никто не удосужился упаковать приложение.
• Никто не имеет права упаковывать приложение (как Oracle настаивает на том, чтобы быть единственным, кто распространяет Java ).
• Пакет публикуется по лицензии, которая противоречит ценностям дистрибутива.
• ...

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

Как установить тарбол?

Тарбол (пакет .tar.gz) может содержать что угодно. Пока вы на самом деле не откроете его, у вас нет возможности предположить, как его установить. Опять же, к каждому пакету следует подходить по-разному.

Ищите документацию! Любой (полу) приличный пакет предоставит инструкции по установке приложения. Ваш первый рефлекс всегда должен искать текстовый файл с именем README, INSTALL или что-то вроде этого. Проверка сайта издателя также может помочь.

Поскольку каждый пакет уникален, универсального способа обработки всех тарболлов в мире не существует. Это все равно что просить рецепт, который работает на всех ингредиентах в мире. Не происходит.

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

Особый случай: Автоинструменты

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

В мире Linux / Open Source / Free Software одна система сборки получила более широкое распространение: GNU Autotools . Если вы когда-либо имели дело с (n открытым) исходным пакетом, есть большая вероятность, что вы будете использовать Autotools.

В простейшем случае вот как установить приложение, упакованное с помощью autotools:

• ./configureСценарий, который будет генерировать файлы Makefile, соответствующие вашей системе (он также часто проверяет наличие зависимостей).
• make: Компиляция исходного кода в соответствии с Makefiles, сгенерированными ранее.
• make installКопирует двоичные файлы в соответствующие места, создает символические ссылки и любые другие действия, определенные разработчиком.

Примечания

• configureСценарии обычно имеют много опций, например, какой компилятор использовать или как определить целевой каталог. Если вам нужна гибкость, стоит посмотреть ./configure --help.
• Даже если вы уверены, что это Autotools и знаете его очень хорошо, всегда начинайте с чтения документов (README, INSTALL, ...)

Ответ на обновление в вопросе

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

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

• В моей системе я резервирую /usr/local/binпакеты, установленные менеджером пакетов. Все, что я собираю / устанавливаю вручную, уходит /opt. Это деталь, но она помогает избежать основных проблем при работе с несколькими версиями одной и той же программы.

• xxx.desktopи проблемы с графическим интерфейсом в целом зависят от используемой среды рабочего стола. Если это работает для вашей системы, отлично. Но это не может быть распространено на все среды, доступные в Unix.

• /usr/local/binимеет преимущество того, что уже находится в вашем ПУТИ . Если вы хотите использовать другой каталог (например, /optкак я предлагаю), обязательно включите его в свой PATH. Если вы не знаете, как это сделать, откройте терминал и выполните в терминале следующее (не самый красивый способ сделать это, но, не зная ничего о вашей системе, я не могу предложить ничего другого):echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Я думаю, что вы должны уточнить с собой, что вы хотите «зарегистрировать» это с .

Чтобы объяснить - и я не пытаюсь быть умным, - «linux» - это, конечно, ядро, и ядро ​​не знает и не интересуется каким-либо программным обеспечением в вашей системе, кроме init. Так о чем мы здесь говорим?

Вы упоминаете ряд разных дистрибутивов. Я иногда создаю программное обеспечение из исходного кода, даже если оно доступно в репозитории, потому что я хочу установить некоторые параметры конфигурации, которые не заданы в двоичном дистрибутиве. Единственная проблема у меня с этим, что если пакет является необходимым условием для чего - то еще, я действительно должен зарегистрировать это с системой упаковки , чтобы избежать случайной установки пакета дистрибутива поверх той , которую я построил. В системах на основе fedora / rpm это делается с помощью rpm -i --justdb <package>. Я не делаю этого в системах на основе Debian / apt; вместо этого я просто принудительно инсталлирую по мере необходимости, что, возможно, лениво - кажется, есть более хороший способ сделать это, создав фиктивный пакет, который претендует на выполнение любого требования. Это похоже на предложение m0nhawk о фактическом создании пакета из источника .tar.gz, за исключением того, что это немного проще (я буду честен и скажу, что мне совсем не нравится предложение m0nhawk).

Похоже, у вас есть другие проблемы, кроме той, что связана с упаковочной системой. Мне не ясно, что это такое, хотя вы упоминаете среду рабочего стола (например, Gnome). Они неоднородны, поэтому просто нет единого ответа на вопрос «как мне сделать это в Linux» - это даже не вопрос «как мне сделать это в Ubuntu» или «как мне сделать это в gentoo "- это вопрос" как мне сделать это для рабочего стола gnome "или" как это сделать на рабочем столе XFCE "и т. д. На мой взгляд, единственная проблема, о которой вы упомянули, это те программы запуска, о которых я хотелось бы верить, что каждый DE предоставляет простой способ сделать это (но это будет не совсем то же самое, потому что они разные).

Затем существуют службы, которые управляются системой инициализации (например, systemd или upstart). Таким образом, этот вопрос на самом деле представляет собой ряд связанных вопросов, касающихся, потенциально:

• система упаковки, например, apt или yum
• система инициализации, например, systemd или upstart
• окружение рабочего стола, например, kde или unity
• файловый браузер, например, nautilus или konqueror
• ?????

Одна из причин, по которой не может быть одного простого унифицированного решения (хотя стандарт XDG может предусматривать некоторые его части), заключается в том, что «linux» не является одной простой унифицированной операционной системой, и я думаю, что подавляющее большинство ее пользователей предпочитают именно это. Я часто вообще не использую DE, и я никогда не использую файловый браузер, с которым они идут, и т. Д.

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

Я думаю, что основная причина вашей общей проблемы заключается в том, что система Linux сама по себе не содержит «реестра» как такового. Исполняемый файл - это все, что вам действительно нужно для запуска. Если вы не хотите указывать полный путь к исполняемому файлу, большинство оболочек будет искать их в каталогах, указанных в переменной окружения $ PATH вашей среды. Это может быть немного сложнее со связанными библиотеками и так далее, но обычно вам не нужно углубляться в это.

Различные дистрибутивы Linux стандартизированы для различных макетов файловых систем и систем управления пакетами, в этом и заключается проблема. Redhats использует rpm , Debians / Ubuntu используют пакеты deb. Арч тоже пошел своим путем . С точки зрения программных проектов, если вы не хотите быть включенным в дистрибутив, ваша пользовательская база полностью находится в одном дистрибутиве, или коммерческий продукт, нацеленный на простоту установки для всех, это, вероятно, единственные точки, которые вы начинаете искать для создания различные пакеты.

На самом деле, исходный файл tar.gz, который собирается с, gccявляется, вероятно, лучшим определением общего «пакета Linux». Ядро Linux с некоторыми утилитами GNU и GCC - это почти общий знаменатель для всех разновидностей операционных систем на основе Linux, которые вы можете получить.

Я бы не сказал, что в виде пакетов доступно так мало вещей, потому что чего-то конкретного, что вы ищете, нет. (или, возможно, дистрибьютор решил не беспокоиться обо всей этой суете пакетов? Как Chrome и его собственный процесс обновления). Там являются так много пакетов вокруг для так многих различных пакетов систем для многих архитектур для так много свободного программного обеспечения его не смешно .

Если вы собрали что-то, что не поставляется в виде пакета для вашего дистрибутива linux, или поддерживает возможность сборки как пакета, лучший способ «зарегистрировать» его как реальный пакет - это создать пакет для него, определяя, где все файлы должны идти в зависимости от выбранной вами системы пакетов и устанавливать ее таким образом. Будьте душой и внесите свою упаковочную работу обратно в проект, чтобы другие могли извлечь из этого пользу.

В Интернете есть различные руководства по созданию пакетов . Debian является одним из них .

Если все, что вы хотите сделать, это запустить скомпилированный пакет, возможно, добавьте бинарный путь к вашему $PATH?

Если вы делаете что-то еще, что это?

Я хотел бы добавить, что вы также можете использовать символическую ссылку ~/bin/вместо /usr/bin. *.desktopфайлы могут быть размещены в ~/.local/share/applications/или /usr/share/applications/. Только я использую свой компьютер, и я стараюсь не касаться системных файлов (что-либо вне моего домашнего каталога) как можно больше.

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

Вот что включено в стандартное значение ~/.profileдля Debian Wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi