it-swarm-ru.tech

Где я должен положить программное обеспечение, которое я сам собираю?

Мне нужно скомпилировать программное обеспечение на моей машине Fedora. Где лучшее место, чтобы положить его так, чтобы не мешать упакованному программному обеспечению?

130
theotherreceive

Практическое правило, по крайней мере, в системах с Debian:

  • /usr/local для материала, который является "общесистемным", т.е. /usr/local обычно в дистрибутиве по умолчанию $PATH и ​​следует стандартной иерархии каталогов UNIX с /usr/local/bin, /usr/local/lib, так далее.

  • /opt для вещей, которые вы не доверяете делать в масштабе всей системы, с префиксами для каждого приложения, т.е. /opt/firefox-3.6.8, /opt/mono-2.6.7, и так далее. Вещи здесь требуют более тщательного управления, но также с меньшей вероятностью сломают вашу систему - и их легче удалить, так как вы просто удаляете папку, и она исчезла.

92
directhex

Если вы действительно не хотите, чтобы это мешало, не помещайте это нигде в вашем $PATH.

Если вы хотите это в $PATH, по крайней мере, не устанавливайте на /usr/local. Я обнаружил, что там выглядит много программного обеспечения, даже если оно установлено дистрибутивом в /usr.

Мой любимый способ установки скомпилированного программного обеспечения - в моем $HOME каталог. Таким образом, вам не нужно использовать Sudo для чего-либо, и он очень хорошо отделен от остальной части вашей системы. Например:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

И если вы хотите, вы можете добавить /home/username/stage/bin на ваш $PATH.

50
Sandy

FHS говорит поместить его в/usr/local там, где дистрибутивы не должны касаться этого. /usr/local/bin для двоичных файлов /usr/local/src для источника и /usr/local/lib для библиотек. Смотрите FHS spec для получения дополнительной информации

21
xenoterracide

Большую часть времени я люблю помещать свои собственные скомпилированные материалы в /opt. Это своего рода псевдостандартное место. Вы также можете рассмотреть /usr/local, но я предпочитаю держать свои вещи на 100% изолированными.

10
Scott Anderson

Поместите их в /usr/local/src.

Что я делаю, так это извлекаю исходный код из этого каталога. Это создаст путь как

/usr/local/src/postgresql-8.3.7

Затем я создаю символическую ссылку на него:

/usr/local/src # ln -s  postgresql-8.3.7 postgresql

Сделайте все ваше здание в /usr/local/src/postgresql.

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

9
Stephen Jazdzewski

Это напоминает мне, мне нужно использовать checkinstall чаще! Таким образом, я просто делаю как обычно

 ./configure
 make

с последующим

 Sudo checkinstall

создать . deb файл ...

6
Kevin Cantu

В соответствии с FHS , /usr/local/ используется для приложений, скомпилированных из исходного кода, а /opt/ используется для сторонних приложений, не поддерживаемых поставщиком операционной системы.

5
Aaron Toponce

Если есть возможность - я бы предложил скомпилировать ваше программное обеспечение, а затем создать пакет FC (я полагаю, он использует yum для установки пакетов программного обеспечения). Затем вы можете установить этот пакет вашего собственного скомпилированного программного обеспечения и удалить его, не испортив всю систему.

5
Eimantas

Если вы хотите легко устанавливать и удалять несколько созданных вами приложений, вы можете использовать Stow в качестве простого менеджера пакетов.

5
Daniel James

Две вещи, которые я бы рекомендовал:

Для всей системы: используйте stow и установите в/usr/local/stow/package-version. Тогда вы можете легко переключаться между версиями.

У меня дома или, если у меня нет разрешений на запись/usr/local, я лично устанавливаю программы в ~/.local, на что намекает стандарт XDG .

Вы также можете использовать Stow локально, хотя я никогда не делал :)

4
elmarco

На самом деле не так сложно создать deb или rpm из исходного архива. Таким образом, вы можете использовать средства диспетчера пакетов вашего дистрибутива для поддержания вашей системы в чистоте. Это то, что я делаю большую часть времени: просто создайте немного оборотов.

3
wzzrd

У меня немного другие настройки, чем у большинства людей, потому что я много занимаюсь разработкой. У меня есть каталог/home/jackson/bin /, в который я устанавливаю материал, и я отредактировал свой .bashrc, добавив это:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

Я бы не стал делать это за все, но это приятно во время разработки.

3
jacksonh

если вы компилируете приложение, вы можете добавить путь к его исполняемым файлам в переменную PATH env. это не повлияет на других пользователей.

2
Hemant

Всегда есть возможность "положить его туда, где он принадлежит", но сначала нужно написать простой rpm.

2
Nils

Если вы хотите, чтобы ваше приложение было доступно для всех пользователей системы, и у вас есть необходимые разрешения, используйте/opt. Если вы хотите, чтобы приложение было доступно только вам (и пользователю root), используйте/home/username

1
Silviu Bogan

Писать RPM, это не сложно, есть руководство по тому, куда положить вещи и делает удаление оснастки.

Если вы сделаете это, установите файлы в /usr а не под /usr/local, как и все другие файлы, которые проходят через систему упаковки.

0
user55149

Самый простой способ сделать это - получить пакет с исходным кодом (.src.rpm для RPMites), распакуйте его, взломайте новый источник/конфигурацию/что угодно в нем, измените версию и соберите. Установка этого позволяет вашему менеджеру пакетов узнать о новом пакете, позволяет рассмотреть его на наличие зависимостей и удалить/обновить.

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

0
vonbrand