rpmsign.c used to actually use "environ" to pass to execve(), but
that call moved to librpmsign a long, long time ago. rpmdb.c and
rpmkeys.c never used it at all but guess it was copy-paste inherited
from rpmsign.c back in the day (dfbaa77152)
rpmgensig.c actually refers to environ, but this is a POSIX required
variable and while Apple has managed to screw it up, it's handled
in system.h and that must be sufficient for all relevant systems
as we also refer to environ in rpmfileutil.c open_dso() and there's
no fake environ definition there. So drop the one in rpmgensig.c too.
The RPM code contains setprogname()/getprogname() support implemented through compatiblity layer with very old GLIBC (internals supported back to '95 and earlier), before stabilization of the GNU C library. This compatiblity layer (__progname, __assert_progname, setprogname()) is supposed to support well archaic GLIBC, but on the other hand it pollutes the library namespace and introduces unpredicable compillation errors on BSD systems.
The functions setprogname() and getprogname() are natively supported in NetBSD and work the same way as __progname from the GNU C library (they are even implemented in the same way - but with a slightly changed logic). The support for very old (20 years and older) GNU C Library is obfuscating the code, because it uses defines over defines without a word of explaination why to do so.
It's important to note that the setprogname()/getprogname() was inconstiently implemented in the codebase, duplicating the code and/or functionality.
Add new generic functions getprogname() and setprogname() and bind it to:
- the current and for two decades stable GNU LIB C implementation,
- the current NetBSD implementation (introduces to NetBSD in 2002),
- fallback reimplementation functions of the setprogname() and getprogname() functionality for other systems.
Don't support anymore old GNU Lib C internals and don't support older NetBSD systems, as they aren't supported for many years.
Add to the codebase comments explaining the relevant codeparts.
- Exportdb simply dumps all the headers from rpmdb into simple header
list which is about as rpm-native and backwards and forwards compatible
format as they come. Importdb obviously, well, imports such a
list into rpmdb.
- Both require transaction handle: we dont want anybody running
transactions while exporting, and importing obviously requires
write-locking.
- The common pattern here is grabbing current flags to a local
variable, modifying them for an operation and then restoring,
which is fine... but we dont care about the previous flags
when we're restoring them.
- It got exposed in the rpmdb tool splitup, but the functionality in
it's current form is still just as dubious as it always was, hide
it out of sight again.
- rpmdb maintenance only requires privileges on the rpmdb directory,
not elsewhere on the system. Splitting to separate tool allows
finer grained SELinux policies and makes adding new db-specific
switches saner.
Panu Matilainen