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

<p>мне нужно скомпилировать программное обеспечение на моей машине fedora. где лучшее место, чтобы положить его так, чтобы не мешать упакованному программному обеспечению?</p>

<p>практическое правило, по крайней мере, в системах с debian:</p><ul> <li> <p><code>/usr/local</code> для материала, который является "общесистемным", т.е. <code>/usr/local</code> обычно в дистрибутиве по умолчанию <code>$path и следует стандартной иерархии каталогов unix с /usr/local/bin, /usr/local/lib, так далее.   /opt для вещей, которые вы не доверяете делать в масштабе всей системы, с префиксами для каждого приложения, т.е. /opt/firefox-3.6.8, /opt/mono-2.6.7, и так далее. вещи здесь требуют более тщательного управления, но также с меньшей вероятностью сломают вашу систему - и их легче удалить, так как вы просто удаляете папку, и она исчезла.  

если вы действительно не хотите, чтобы это мешало, не помещайте это нигде в вашем $path</code>.</p><p>если вы хотите это в <code>$path, по крайней мере, не устанавливайте на /usr/local. я обнаружил, что там выглядит много программного обеспечения, даже если оно установлено дистрибутивом в /usr.мой любимый способ установки скомпилированного программного обеспечения - в моем $home</code> каталог. таким образом, вам не нужно использовать <code>sudo</code> для чего-либо, и он очень хорошо отделен от остальной части вашей системы. например:</p><pre><code>mkdir ~/stage ./configure --prefix=/home/username/stage && make && make install </code></pre><p>и если вы хотите, вы можете добавить <code>/home/username/stage/bin</code> на ваш <code>$path.

 <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#usrlocallocalhierarchy">fhs говорит поместить его в/usr/local там, где дистрибутивы не должны касаться этого. /usr/local/bin для двоичных файлов /usr/local/src для источника и /usr/local/lib для библиотек. смотрите <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#usrlocallocalhierarchy">fhs spec для получения дополнительной информации

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

поместите их в /usr/local/src.что я делаю, так это извлекаю исходный код из этого каталога. это создаст путь как/usr/local/src/postgresql-8.3.7 затем я создаю символическую ссылку на него:/usr/local/src # ln -s postgresql-8.3.7 postgresql сделайте все ваше здание в /usr/local/src/postgresql.подобные действия помогают, когда вам нужно переключиться между версиями и документами, какую версию вы используете.

это напоминает мне, мне нужно использовать <strong> <a href="http://www.linuxjournal.com/content/using-checkinstall-build-packages-source">checkinstall </strong> чаще! таким образом, я просто делаю как обычно ./configure make с последующим sudo checkinstall создать <strong>. deb </strong> файл ...

в соответствии с <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html"> fhs  , /usr/local/ используется для приложений, скомпилированных из исходного кода, а /opt/ используется для сторонних приложений, не поддерживаемых поставщиком операционной системы.

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

если вы хотите легко устанавливать и удалять несколько созданных вами приложений, вы можете использовать <a href="http://savannah.gnu.org/projects/stow">stow в качестве простого менеджера пакетов.

две вещи, которые я бы рекомендовал:для всей системы: используйте <a href="http://www.gnu.org/software/stow/">stow и установите в/usr/local/stow/package-version. тогда вы можете легко переключаться между версиями.у меня дома или, если у меня нет разрешений на запись/usr/local, я лично устанавливаю программы в ~/.local, на что намекает <a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">стандарт xdg .вы также можете использовать stow локально, хотя я никогда не делал :)

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

у меня немного другие настройки, чем у большинства людей, потому что я много занимаюсь разработкой. у меня есть каталог/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 </code></pre><p>я бы не стал делать это за все, но это приятно во время разработки.</p>

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

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

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

<p>писать rpm, это не сложно, есть руководство по тому, куда положить вещи и делает удаление оснастки.</p><p>если вы сделаете это, установите файлы в <code>/usr</code> а не под <code>/usr/local</code>, как и все другие файлы, которые проходят через систему упаковки.</p>

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