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
/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
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.