How do you separate /bin and /sbin when making an RPM?

Question

I'm trying to make a redis RPM using fpm

When I run the following commands, all binaries are installed to /tmp/installdir/usr/local/bin

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

How could I compile redis so that the redis-server binary is installed to /tmp/installdir/usr/local/sbin and everything else (redis-cli, redis-benchmark ect.. ) is installed to /tmp/installdir/usr/local/bin ?

Answer 1

The fpm dev has this to say on the subject of distribution-specific guidelines:

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)

So, the default behavior you are observing, where everything is placed in /usr/local/bin seems to be the group's preference. And they are not alone; not only Fedora & co but also freedesktop.org agree with merging /bin and /sbin into /usr/bin. While the current draft of the FSH still uses sbind directories, there does seem to be a movement building against them.

In any case, the Fedora people have some very good arguments against sbin which include (emphasis mine):

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. [...]

These points were made about /sbin, but they seem equally applicable to /usr/local/sbin. So, while @slm gave you what I'm sure is the way to do what you're actually asking for, it might be better to just ignore sbin and let fpm do its thing.

Answer 2

If you want to take control of where various files will be installed you'll have to take responsibility for manually doing this within your RPM .spec file directly.

Example

Here's a snippet from a JBOSS RPM .spec file that I created in a blog series I wrote up a couple of years ago. The article in this series is titled: 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}/*
...

In the above %install stanza you'll need to specify where in your $RPM_BUILD_ROOT you'd like the software to be "installed" to. Here's where you can make your sbin and bin directories respectively.

When categorizing the files you've "installed" with this RPM, you'll need to reflect their locations in the %files section. You can facilitate this a bit by creating bulid macros in your $HOME/.rpmmacros file if you find you're making the same ones all the time.

For example, I have a %_topdir macro that I use when building things, like so:

%_topdir %(echo $HOME)/rpmbuild

These macros can then be utilized in your .spec files.