Стандарт иерархии файловой системы (неправильно названный - это не стандарт) будет очень полезен для вас; в нем четко описаны предпочтения администратора относительно места хранения данных.
Поскольку вы впервые упаковываете свое программное обеспечение, я бы порекомендовал сделать очень мало . Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD и т. Д. Имеют свои небольшие особенности того, как лучше всего упаковывать программное обеспечение.
Строительство
Лучше всего предоставить исходный архив, который создает , и надеяться, что пользователи или упаковщики этих дистрибутивов подберут его и упакуют для вас. Пользователи, вероятно, подойдут для загрузки архива, распаковки, компиляции и установки.
Для сборки вашего программного обеспечения make(1) является обычным стандартом. Существуют и другие инструменты, но этот доступен везде и довольно разумный. (Даже если синтаксис капризный .) Пользователи ожидают, что смогут запустить: make ; make install или ./configure ; make ; make install для сборки и установки программного обеспечения в /usr/local по умолчанию. (./configure является частью autotools toolchain; особенно удобно, если предоставить ./configure --prefix=/opt/foo, чтобы пользователи могли менять место установки программного обеспечения с одним параметром командной строки. Я бы старался избегать автоинструментов до сих пор как можно, но в какой-то момент легче написать переносное программное обеспечение с ими, чем без их.)
Упаковка
Если вы действительно хотите обеспечить комплексную упаковку, то в Руководстве по политике Debian будут представлены канонические правила для упаковки вашего программного обеспечения. Руководство для новых сопровождающих Debian предоставит более подробное и понятное описание инструментов, уникальных для создания пакетов для систем Debian и производных от Debian.
Руководство по упаковке Ubuntu может содержать подробности, относящиеся к Ubuntu. (Я еще не читал.)
Конфигурация
Когда дело доходит до файла конфигурации вашего приложения, обычно файл сохраняется в /etc/<foo>, где <foo> представляет программу / пакет. См. /etc/resolv.conf для получения подробной информации о разрешении имен, /etc/fstab для списка устройств, которые содержат файловые системы и где их монтировать, /etc/sudoers для конфигурации sudo(8), /etc/apt/ для apt(8) системы управления пакетами и т. Д. .
Иногда приложения также предоставляют настройку для каждого пользователя; эти конфигурационные файлы часто хранятся в ~/.foorc или ~/.foo/, если весь каталог более полезен, чем файл. (См. ~/.vim/, ~/.mozilla/, ~/.profile и т. Д.)
Если вы также хотели предоставить параметр командной строки -c <filename>, чтобы сообщить вашей программе использовать нестандартный файл конфигурации, который иногда оказывается удобным real . (Особенно, если ваши пользователи могут запустить foo -c /dev/null для запуска с настройками по умолчанию.)
Файлы данных
Пользователи будут хранить свои данные в своем домашнем каталоге. Вам не нужно ничего делать с этим; просто убедитесь, что поля навигации по каталогу начинаются с getenv("HOME") или загружаете файлы конфигурации с помощью sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); или что-то подобное. (У них не будет разрешений на запись где угодно, кроме их домашнего каталога и /tmp/ на большинстве сайтов.)
Иногда все данные могут храниться в скрытом файле или каталоге; Например, ssh(1) сохраняет все свои данные в ~/.ssh/. Как правило, пользователи хотят, чтобы имя kry по умолчанию было ssh-keygen(1), поэтому ssh-agent(1) может найти ключ с минимумом суеты. (По умолчанию используется ~/.ssh/id_rsa.) Диспетчер фотографий shotwell(1) обеспечивает управляемый опыт, аналогичный iPhoto.app от Apple. Он позволяет пользователям выбирать начальный каталог, но в противном случае упорядочивает файлы и каталоги внутри по своему усмотрению.
Если ваше приложение является программой общего назначения, вы, вероятно, позволите своим пользователям выбирать свои собственные имена файлов. Если они хотят сохранить данные непосредственно на карту памяти, смонтированную в /dev или /media, или в удаленную файловую систему, смонтированную в /automount/blah, их домашние каталоги, каталог /srv/ для содержимого, обслуживаемого на машине, или /tmp/ , позволь им. Это зависит от пользователей, чтобы выбрать разумные имена файлов и каталогов для своих данных. Пользователи должны иметь соответствующие права доступа уже . (Не пытайтесь предоставлять пользователям механизмы для записи в местах, где у них нет привилегий.)
Установка приложения и владение файлом
Существует два распространенных способа установки приложения в системе Linux:
Администратор устанавливает его один раз для всех. Это обычно. Программы принадлежат root или bin или adm или какой-либо подобной учетной записи. Программы запускают в зависимости от того, какой пользователь их выполняет, поэтому они получают права пользователя на создание и чтение файлов. Если они упакованы с файлами пакетов распространения, исполняемые файлы обычно будут жить в /usr/bin/, библиотеки в /usr/lib/, а не-объектные файлы (изображения, схемы и т. Д.) Будут жить в /usr/share/. (/bin/ и /lib/ предназначены для приложений, необходимых при ранней загрузке или для аварийных сред. /usr может быть общим для всех машин в сети, смонтированных только для чтения в конце процесса загрузки.) (См. FHS для полная информация.)
Если программы распакованы, то /usr/local/ будет отправной точкой: /usr/local/bin/, /usr/local/lib/, /usr/local/share/ и т. Д. Некоторые администраторы предпочитают /opt/.
Пользователи устанавливают приложения в свой домашний каталог. Это не так часто, но у многих пользователей есть каталог ~/bin/, в котором они хранят сценарии оболочки или программы, которые они пишут, или ссылаются в программах из каталога ~/Local/<foo>/. (В этом имени нет ничего волшебного. Это было первое, о чем я подумал много лет назад. Другие выбирают другие имена.) Именно здесь ./configure --prefix=~/Local/blah окупается.)