Como você separa / bin e / sbin ao fazer um RPM?

Question

Estou tentando fazer um RPM de redis usando fpm

Quando executo os seguintes comandos, todos os binários são instalados em / tmp / installdir / usr / local / bin

cd /tmp/redis2-8
PREFIX=/tmp/installdir/usr/local/ make 
PREFIX=/tmp/installdir/usr/local/ make install 

Como eu poderia compilar os redis para que o binário redis-server fosse instalado para /tmp/installdir/usr/local/sbin e tudo o mais ( redis-cli, redis-benchmark ect ..) fosse instalado para /tmp/installdir/usr/local/bin ?

    

Answer 1

O fpm dev tem isto a dizer sobre o assunto de diretrizes específicas de distribuição:

I want a simple way to create packages without all the bullshit. In my own infrastructure, I have no interest in Debian policy and RedHat packaging guidelines - I have interest in my group's own style culture and have a very strong interest in getting work done.

(This is not to say that you can't create packages with FPM that obey Debian or RedHat policies, you can and should if that is what you desire)

Assim, o comportamento padrão que você está observando, onde tudo é colocado em /usr/local/bin , parece ser a preferência do grupo. E eles não estão sozinhos; não só o Fedora & co mas também freedesktop.org concorda com a fusão de /bin e /sbin em /usr/bin . Embora o rascunho atual do FSH ainda use diretórios sbind , parece haver um movimento de construção contra eles.

Em qualquer caso, o pessoal do Fedora tem alguns argumentos muito bons contra sbin que incluem (ênfase minha):

a) the split between sbin and bin requires psychic powers from
upstream developers:

The simple fact is that moving binaries between these dirs is really hard, and thus developers in theory would need to know at the time they first introduce a binary whether it ever might ever make sense to invoke it as unprivileged user (because in that case the binary belongs in /bin, not /sbin). History shows that more often than not developers have placed their stuff in the wrong directory, see /sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart way to fix things anymore since changing paths means breaking all hardcoded scripts. And hardcoding paths in scripts is actually something we encourage due to perfomance reasons. The net effect is that many upstream developers unconditionally place their stuff in bin, and never consider sbin at all which undermines the purpose of sbin entirely (i.e. in systemd we do not stick a single binary in sbin, since we cannot be sure for any of its tools that it will never ever be useful for non-root users. and systemd is as low-level, system-specific it can get).

b) The original definition of /sbin is fully obsolete (i.e. the "s" in sbin stood originally for "static" binaries)

c) /bin vs. /sbin is not about security, never has been. Doing this
would be security by obscurity, and pretty stupid, too.

d) splitting /bin off /sbin is purely and only relevant for $PATH, and $PATH is purely and only something to ease access to the tools in it for shell users. The emphasis here is on "ease". It is not a way to make it harder for users to access some tools. Or in other words: if your intention is to hide certain tools from the user in order not to confuse him, then there are much better places for that: the documentation could document them in a separate section or so. I don't think it makes any sense at all trying to educate the user by playing games with what he can see if he presses TAB in the shell. [...]

Esses pontos foram feitos sobre /sbin , mas eles parecem ser igualmente aplicáveis a /usr/local/sbin . Então, enquanto @slm deu a você o que eu tenho certeza que é a maneira de fazer o que você está realmente pedindo, pode ser melhor simplesmente ignorar sbin e deixar fpm fazer sua parte.

    

Answer 2

Se você quiser controlar onde vários arquivos serão instalados, você terá que assumir a responsabilidade de fazer isso manualmente no arquivo RPM .spec diretamente.

Exemplo

Aqui está um trecho de um arquivo JBOSS RPM .spec que eu criei em uma série de blogs que escrevi há alguns anos. O artigo desta série é intitulado: Tutorial do RPM do CentOS Parte 3 - Criando seu próprio RPM do 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}/*
...

Na estrofe %install acima, você precisará especificar em que parte do seu $RPM_BUILD_ROOT deseja que o software seja "instalado". Aqui é onde você pode criar seus diretórios sbin e bin , respectivamente.

Ao categorizar os arquivos que você "instalou" com esse RPM, você precisará refletir seus locais na seção %files . Você pode facilitar isso criando macros volumosas no seu arquivo $HOME/.rpmmacros se descobrir que está fazendo as mesmas o tempo todo.

Por exemplo, eu tenho uma macro %_topdir que uso ao criar coisas, assim:

%_topdir %(echo $HOME)/rpmbuild

Essas macros podem ser utilizadas em seus arquivos .spec .