LINUX.ORG.RU

Установка пакета

 ,


0

1

Добрый день. Вопрос: куда программе класть изменяемый данные и как это реализовать?

Я вот что думаю: Имеется /var и /var/local для usr/local, т.е. мы должны настроить путь во время установки, ведь пользователь может написать ./configure, а может ./configure --prefix=/usr. Autotools не берёт на себя эту работу и тупо задаёт для имзеняемых данных localtsatedir==$(prefix)/var.

Что делать? 1. Не устанавливать в /var, в каждом $(prefix) создавать свою var. Но вроде это неправильно. 2. В каждом $(prefix) создавать ссылку на нужный var (/var или /var/local). Если перекинуть задачу на конечного пользователя, то как-то не очень, если он использует менеджер (например xstow), то в каждой поддиректории программы нужно делать ссылку. А может заложить алгоритм в configure? Если в $(prefix) нашли local, то создаём ссылку на /var/local, иначе на /var.

★★

Ответ на: комментарий от alfix
$ man hier | grep local -A 2

/usr/local
    This is where programs which are local to the site typically go.
/usr/local/bin
    Binaries for programs local to the site.
/usr/local/doc
    Local documentation.
/usr/local/etc
    Configuration files associated with locally installed programs.
/usr/local/games
    Binaries for locally installed games.
/usr/local/lib
    Files associated with locally installed programs.
/usr/local/include
    Header files for the local C compiler.
/usr/local/info
    Info pages associated with locally installed programs.
/usr/local/man
    Man pages associated with locally installed programs.
/usr/local/sbin
    Locally installed programs for system administration.
/usr/local/share
    Local application data that can be shared among different architectures of the same OS.
/usr/local/src
    Source code for locally installed software.
/var/local
    Variable data for /usr/local.
pavlick ★★
() автор топика

Если перекинуть задачу на конечного пользователя, то как-то не очень, если он использует менеджер (например xstow), то в каждой поддиректории программы нужно делать ссылку. А может заложить алгоритм в configure? Если в $(prefix) нашли local, то создаём ссылку на /var/local, иначе на /var.

Уууу. Иди смотри исходники бородатых программ для BSD, Solaris. Всё, что связано с /var должен делать только админ. Идиот-пользователь настроит права криво, в логах просветятся пассы/другая приватная инфа и алё, кто хочет, тот читает.

Если делать современно, то dpkg, rpm[build] должны делать все это за тебя. С твоей стороны лишь адекватно проставить права. Тем, кто будет собирать твое чудо из исходников, можешь написать shell-скрипт.

А если уходить еще дальше, то храни все в /usr, ибо Леня так завещал (и плевал на HFS, LSB %)

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

Пишу для себя, хочется понять как делать правильно. Внятного объяснения не встречал (как разрешать потенциальные конфликты имён?). Для себя наметил такую схему: 1. Ставлю в /usr/local/xstow/pkg_name 2. Если появилось /usr/local/xstow/pkg_name/var, то создаю в /var/local/ директорию с уникальным именем (номер, например). 3. Запускаю ./configure --localstatedir=созданая_директория

В итоге, /var/local конфликты имён исключаю руками, в остальных общих директориях отслеживает xstow. Кончено можно не париться с /var/local, в качестве «правильной» схемы на крайняк.

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

Для себя наметил такую схему

ИМХО, лучше так не делать. Либо кидать ошибку. Либо переименовывать проект. Кстати, если имя проекта уже забито, то уже проблемы, нетехнического характера и решается либо выкупанием ТМ (трейдмарка, пусть и потенциального) или переименовываем проект в незанятое.

Касательно /var. Я не знаю, что у тебя. Однако, /var используется в след. случаях:

  • Логи
  • Файлы unix domain socket
  • Приватные данные, которые хранит программа на этапе эксплуатации и никогда их не трогает при сборке/инсталляции и т.п. Как пример postfix. Доступ к ним может быть только у админа.
gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 2)
Ответ на: комментарий от pavlick

В старых программах было принято следующее. Программа валится, когда не создана нужная директория в /var/program; когда не выставлены корректные права на нее (необязательно); программа валится, когда не создан нужный файл, как пример, некоторый софт только открывает и пишет в /var/prog/prog.pid. Казалось бы, простой pid-файл, что в нем страшного? Так, вот, было принято, что этот файл должен создать админ (touch /var/prog/prog.pid) и, опять же, выставить на него нужные права.

Часть софта в том же дебиане, еще жила по этим правилам. Позднее (лет 5-7 назад) начали от этого избавляться. Пришлось патчить сорцы некоторых программ, т.к. такое поведение и даже пути были зашиты внутрь исходников/бинарников.

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

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

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

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