Как Вы разделяете / мусорное ведро и/sbin при создании об/мин?
Это спросили прежде на stackoverflow. Вот принятый ответ:
Можно присоединить к сессии Emacs через emacsclient. Во-первых, запустите emacs сервер с
M-x запускаются сервер или добавляют (запускаются сервер) к Вашему .emacs. Затем
экспортируйте Редактирование VISUAL=emacsclient далеко.
Примечание:
- Версии emacs и emacsclient должны согласиться. Если у Вас есть несколько версий установленного Emacs, удостоверьтесь, что Вы вызываете версию соответствия emacsclient версии Emacs, выполняющего сервер.
- При запуске сервера в нескольких процессах/кадрах Emacs (например, потому что (запуск сервер) находится в .emacs), буфер будет создан в последнем кадре для запуска сервера.
У fpm dev есть вот что сказать по поводу руководства для конкретных дистрибутивов:
Я хочу простой способ создания пакетов без всякой ерунды. В моей собственной инфраструктуре меня не интересует политика Debian и руководство по упаковке RedHat - меня интересует культура стиля моей группы и очень сильный интерес к выполнению работы.
(Это не значит, что вы не можете создавать пакеты с FPM, которые подчиняются политике Debian или RedHat, вы можете и должны, если вы этого хотите)
Итак, поведение по умолчанию, которое вы наблюдаете, где всё помещается в /usr/local/bin, похоже, является предпочтением группы. И они не одиноки; не только Fedora & co, но и freedesktop.org согласны с объединением /bin и /sbin в /usr/bin. Хотя в текущем проекте FSH по-прежнему используются каталоги sbind, похоже, что против них развивается движение.
В любом случае, у людей Fedora есть несколько очень хороших аргументов против sbin, которые включают (выделение моё):
a) разделение sbin и bin требует экстрасенсорных способностей от
Простой факт заключается в том, что перемещать двоичные файлы между этими каталогами очень сложно, и поэтому разработчики теоретически должны знать, когда они впервые представляют двоичный файл, имеет ли смысл когда-либо вызывать его от имени непривилегированного пользователя (потому что в этом случае двоичный файл должен находиться в /bin, а не в /sbin). История показывает, что чаще всего разработчики помещают свои вещи в неправильный каталог, см. /sbin/arp, /sbin/ifconfig, /usr/sbin/httpd, и тогда уже нет разумного способа исправить ситуацию, поскольку изменение путей означает нарушение всех жестко закодированных скриптов. А жесткое кодирование путей в скриптах - это то, что мы поощряем по причинам производительности. Чистый эффект заключается в том, что многие разработчики upstream безоговорочно помещают свои материалы в bin и вообще не рассматривают sbin, что полностью подрывает цель sbin (например, в systemd мы не помещаем ни одного бинарника в sbin, поскольку мы не можем быть уверены в том, что любой из его инструментов никогда не будет полезен для пользователей без рута. а systemd - это настолько низкоуровневый, специфичный для системы продукт, насколько это возможно).
б) Оригинальное определение /sbin полностью устарело (т.е. "s" в sbin первоначально обозначала "статические" двоичные файлы)
c) /bin vs. /sbin не относится к безопасности, и никогда не относилось. Делать это
было бы безопасностью по неясности, и довольно глупо, к тому же.d) разделение /bin и /sbin имеет значение только для $PATH, и $PATH - это исключительно и только то, что облегчает доступ к инструментам в нем для пользователей shell. Акцент здесь сделан на "облегчить". Это не способ усложнить пользователям доступ к некоторым инструментам. Или другими словами: если ваше намерение состоит в том, чтобы скрыть определенные инструменты от пользователя, чтобы не запутать его, то для этого есть гораздо лучшие места: документация могла бы документировать их в отдельном разделе или около того. Я не думаю, что имеет смысл пытаться обучать пользователя, играя в игры с тем, что он может увидеть, если нажмет TAB в оболочке. [...]
Эти замечания были сделаны по поводу /sbin, но они кажутся одинаково применимыми к /usr/local/sbin. Поэтому, хотя @slm дал вам то, что, я уверен, является способом сделать то, о чем вы просите, возможно, лучше просто игнорировать sbin и позволить fpm делать свое дело.
Если вы хотите взять под контроль то, куда будут установлены различные файлы, вам придется вручную сделать это в вашем файле RPM .spec.
Пример
Вот фрагмент из файла JBOSS RPM .spec, который я создал в серии блогов, написанных пару лет назад. Статья из этой серии называется: CentOS RPM Tutorial Part 3 - Building your own RPM of JBoss.
...
%prep
%setup -q
%build
%install
rm -fr $RPM_BUILD_ROOT
mkdir -m 0755 -p $RPM_BUILD_ROOT/opt/%{name}/%{name}-%{version}
cp -R * $RPM_BUILD_ROOT/opt/%{name}/%{name}-%{version}
%clean
rm -rf $RPM_BUILD_ROOT
%post
echo " "
echo "install of jboss complete!"
%files
%defattr(-,root,root)
/opt/%{name}/*
...
В приведенной выше строфе %install вам нужно указать, куда в вашем $RPM_BUILD_ROOT вы хотите "установить" программное обеспечение. Вот где вы можете сделать каталоги sbin и bin соответственно.
При распределении файлов, которые вы "установили" с помощью этого RPM, вам нужно будет отразить их местоположение в разделе %files. Вы можете немного облегчить эту задачу, создав макросы bulid в файле $HOME/.rpmmacros, если вы обнаружите, что постоянно создаете одни и те же макросы.
Например, у меня есть макрос %_topdir, который я использую при сборке вещей, вот так:
%_topdir %(echo $HOME)/rpmbuild
Эти макросы можно использовать в файлах .spec.