This file contains a number of ideas and suggestions and references
to other documentation which might come in helpful in case you are
packaging beep for a Linux distribution.
In addition, to a packager of beep, INSTALL.md might also be
interesting.
The building and installing during a package build can be achieved with
make
make install DESTDIR=/path/to/package-root CC=falseWhile not strictly necessary, the CC=false makes sure
that no compilation happens during the make install
phase.
You can also add to the default compiler flags by setting or adding
to CFLAGS, CPPFLAGS, LDFLAGS, and
LIBS, by running make like e.g.
make CFLAGS="-O -g -flto=auto -ffat-lto-objects" CPPFLAGS="-I/opt/include" LDFLAGS="-f" LIBS="-L/opt/lib"The buildsystem will use whatever compiler CC is set to.
clang and gcc are known to work, other
toolchains might.
make CC=clangIf you need to set any of the *dir variables like
prefix or docdir on the make
command line, you need to set them for both the build step
(make) and for the install step
(make install). You might either give the very same command
line for every invocation of make, or you can write those
definitions into a make include file called local.mk once.
For example, you might want to achieve the effect of
make prefix='/usr' docdir='$(docdir)/$(PACKAGE_TARNAME)-$(PACKAGE_VERSION)'
make prefix='/usr' docdir='$(docdir)/$(PACKAGE_TARNAME)-$(PACKAGE_VERSION)' DESTDIR=/path/to/package-root installby creating a local.mk which might look as follows in
e.g. an RPM spec file:
cat>local.mk<<EOF
prefix = %{_prefix}
docdir = %{_pkgdocdir}
EOF
make
make install DESTDIR='%{buildroot}'or in a Debian debian/rules.mk file (something along
these lines, untested):
override_dh_auto_configure:
echo 'CC = $(CC)' > local.mk
echo 'prefix = /usr' >> local.mk
echo 'CFLAGS = $(shell dpkg-buildflags --get CFLAGS)' >> local.mk
/usr/bin/beep
The beep executable.
/usr/share/man/man1/beep.1
Man page for the beep executable.
If your distribution package ships a special
README.Distro file (such as README.Debian or
README.fedora), you might want to add a reference to that
file in the man page's SEE ALSO section instead of the
commented out placeholder reference to
README.Distro.
/usr/share/doc/beep/README.md
General description of beep.
/usr/share/doc/beep/PERMISSIONS.md
Gives package users and system administrators the information they need
to successfully set up device permissions for non-root users.
Covers installing from source tree, and distro package following and not following the beep suggested udev rule setup.
/usr/share/doc/beep/NEWS.md
/usr/share/doc/beep/COPYING
/usr/share/doc/beep/CREDITS.md
The files INSTALL.md, DEVELOPMENT.md, PACKAGING.md are not useful for
binary packages. They only make sense for source trees.
/etc/modprobe.d/pcspkr-beep.conf
When the system administrator uncomments the alias line,
this tells the system to load the pcspkr.ko kernel
module:
alias platform:pcspkr pcspkr
Without pcspkr.ko loaded, there will be no sound from
the PC speaker at all.
Use, change, replace as is fitting for your distribution.
/usr/lib/udev/rules.d/70-pcspkr-beep.rules or
/lib/udev/rules.d/70-pcspkr-beep.rules (location depends on
distribution)
If you want to use the suggested permission setup, ship this file.
For the contents, cf. PERMISSIONS.md.
Use, change, replace as is fitting for your distribution.
/usr/lib/udev/rules.d/90-pcspkr-beep.rules or
/lib/udev/rules.d/90-pcspkr-beep.rules (location depends on
distribution)
If you want to use the suggested permission setup, ship this file.
For the contents, cf. PERMISSIONS.md.
Use, change, replace as is fitting for your distribution.
Shipping the two permission approaches
(TAG+="uaccess" and the group based one) in separate udev
rule files allows the sysadmin to override or completely disable either
one of those rules by placing a file of the same name into
/etc/udev/rules.d/, which does not require changing things
in /usr which might be a readonly filesystem or be
overwritten by the next update of the beep packge.
Add a beep system user group
If you want to use the suggested permission setup (cf. PERMISSIONS.md), have the package
run something like e.g.
# Fedora, RHEL, etc.
getent group beep >/dev/null || groupadd --system beep
# Debian, Ubuntu, etc.
getent group beep >/dev/null || addgroup --system beep
inside the package installation scripts.
/usr/share/doc/beep/PERMISSIONS.md
The PERMISSIONS.md file
describes to system administrators how to give users permissions to
actually beep the PC speaker, both with the suggested udev rules, and
generally.
If your distribution ships a different set of udev rules, you should
describe those in some distribution specific README file (like e.g.
README.Debian or README.fedora).
All files installed into /etc are config files which the
system administrator may change and expect to not be overwritten with
package updates.
The sysadmin may add their own udev rules to
/etc/udev/rules.d/ which should not be touched by the
beep package.
beep was written for the x86 platform, and works on both
32bit and 64bit x86 platforms.
EV_SND/SND_TONE
interfaceFrom a cursory glance through the Linux kernel source code, there
appear to be a number of devices implementing the same
EV_SND/SND_TONE evdev interface
pcspkr.ko implements, like e.g. m68kspkr or
sparcspkr.
It would be interesting to know on which non-PC platforms
beep actually makes sense. The S/390 e.g. probably does not
belong to the systems where beeper hardware is to be expected.
pcspkr.ko or other
EV_SND/SND_TONE devicesFor platforms without a PC speaker, packaging beep only makes sense if there is both hardware support for beeping, and software support for that hardware.
At this time, beep provides no software support for any
of those platforms.
The following is a list of links to some distributions' packages of
beep:
Raspbian
Sources: See Debian.
Ubuntu
http://packages.ubuntu.com/src:beep
Sources: See Debian.
More information on miscellaneous distributions' beep
packages can be found at the repology.org beep
page.