LINUX.ORG.RU

Куда ставить то?


0

0

Здравствуйте!

Никак не могу понять куда мне ставить программы то, если я их ставлю из исходников. То в /usr, то в /usr/local. Ну не понимаю я...

И второй вопрос. Энное количество программ ставятся в /opt. Вопрос: как вписсывать в PATH? Я пока сделал каталог /opt/bin куда складываю симлинки на реальные /opt/prog/bin/prog и сответственно добавил /opt/bin в PATH. Но хочется знать как кошернее-то?

Спасибо.


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

Sherak ★☆
()

Эээ.. make install отменили?

dGhost ★★★
()
Ответ на: комментарий от PEGAS

Хочешь стать профессиональным собирателем софта или просто нечем реально заняться? Тогда добро пожаловать в Генту! Тонны бессмыслено убитого времени тебе гарантированы:)

По теме: обычно сторонний софт принято ставить в /opt или /usr/local, но иногда бывает нужно поставить по префиксу дистрибутивного софта. Хотя это всё условности, жёстких требований нет. А если ты спрашиваешь о дистрибутивном софте, то тут тоже есть варианты. ИМХО вопрос похож на "как лучше назвать каталог с музыкой - muzik, music, muzlo или audio?".

Sherak ★☆
()

> Вопрос: как вписсывать

Это тебе к врачу надо! :-)

lonki-lomki
()

Симлинков в bin не всегда бывает достаточно.
Есть же еще lib с so-шками и *.pc файлы.

Я, обычно, ставлю программы в /usr/local/
(configure --prefix=/usr/local/...),
а затем, по мере необходимости, делаю ссылки
на исполняемые файлы в /usr/local/bin,
на *.so в /usr/local/lib, а на .pc в
/usr/local/lib/pkgconfig

Последнее актуально только при сборке программ,
поэтому можно заменить просто добавлением нового пути
к pkgconfig перед configure, например:
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/FUSE/lib/pkgconfig

lonki-lomki
()

Если надо чтоб кошерно, есть epkg (http://encap.org/epkg) специально для такого случая -- когда и /usr поганить жалко, и родной менеджер пакетов неприменим.

А вообще, можно и в /usr/local ставить.

lodin ★★★★
()
Ответ на: комментарий от PEGAS

> Мои текущие задачи все же несколько отличны от "поставить в один клик и использовать".

И что же у тебя за задачи?

troorl ★★
()
Ответ на: комментарий от troorl

есть много таких задач.
например собрать gnuplot 4.2.2 - ни в одном дистре ещё этой сборки нету, увы. Чем отличается 4.2.2 от 4.0 специалисты поймут.

Или например новый гимп, или audacity. для них ещё надо обновить gtk+-2.0 и т.д. Обновление это тянет на 266 МБ, что в условиях 2р за метр честно говоря, не совсем приемлимо.

кашерна - эта в Маскве. у нас ф правинции эта никашерна.

scyld
()
Ответ на: комментарий от scyld

У любого нормального дистра есть девелные репозитории, которые содержат самое последнее ПО (посмотрел альтовый сизиф - в нём есть гнуплот 4.2.2). А для экономии трафика некоторые дистрибутивы (напр. Сюзи и та же Гента) позволяют скачивать не весь пакет, а его дифф, что будет даже экономнее чем то что ты делаешь сейчас.

Sherak ★☆
()
Ответ на: комментарий от Sherak

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

поэтому я ещё раз п-о-в-т-о-р-я-ю : 266МБ для обновления библиатек ф правинции никашерна.

scyld
()
Ответ на: комментарий от scyld

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

Ты серьёзно думаешь что скачивание сорцов + ручная сборка смогут радикально уменьшить трафик и количество зависимостей? Очевидно только за счёт глубокого самовнушения :)

Sherak ★☆
()
Ответ на: комментарий от scyld

что самое интересное, смысл этих цифр известен только тебе и паре-тройке телепатов.

Sherak ★☆
()

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

Sherak ★☆
()

Да я просто хотел понять куда же что ставить в принципе, как задумывалось. Использовать пакеты от дистрибутива -- это, конечно, самый простой и правильный способ, однако, если я хочу понять принципы сувания софта туда или туда...

Ладно, с /usr/ и /usr/local хрен с ними, а вот про /opt то кто-нить мну просветит? Вот установил я Java она устанавливаетя в /opt, мне надо ручками вводить в консоли java prog_name и соответственно javac progname. Визуальщину не предлагать.

ЗЫ1 Дистр, если что Arch.
ЗЫ2 Опять из ничего флейм развели.
ЗЫ3 Ушел глядеть в Arch установщике пакетов как он разруливает это все...

PEGAS
() автор топика
Ответ на: комментарий от Sherak

Твое мнение я уже понял -- ты его пять раз уже произнес. Спасибо, можешь больше не продолжать.

Другие мнения будут?

PEGAS
() автор топика
Ответ на: комментарий от PEGAS

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

Sherak ★☆
()
Ответ на: комментарий от Sherak

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

PEGAS
() автор топика
Ответ на: комментарий от PEGAS

> Ладно, с /usr/ и /usr/local хрен с ними,
> а вот про /opt то кто-нить мну просветит?
А чем, принципиально, /usr/local отличается от /opt?
Да, ставь хоть в /vasya, просто, добавь в PATH /vasya/bin
в /etc/ld.so.conf /vasya/lib, в PKG_CONFIG_PATH /vasya/lib/pkgconfig

lonki-lomki
()
Ответ на: комментарий от PEGAS

Отсюда: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

/opt : Add-on application software packages

Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name. Requirements

Directory Description

<package> Static package objects

<provider> LANANA registered provider name

The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.

Programs to be invoked by users must be located in the directory /opt/<package>/bin or under the /opt/<provider> hierarchy. If the package includes UNIX manual pages, they must be located in /opt/<package>/share/man or under the /opt/<provider> hierarchy, and the same substructure as /usr/share/man must be used.

Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.

Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.

No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.

Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator. Rationale The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.

The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.

Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt.

The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.

The structure of the directories below /opt/<provider> is left up to the packager of the software, though it is recommended that packages are installed in /opt/<provider>/<package> and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/<provider>/lib or /opt/<provider>/bin.

lodin ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.