Reuben Thomas wrote: > If you still don't agree, then I suggest: "The package systems of most > GNU/Linux distributions."
The same problem exists for distros on macOS (MacPorts, Fink, ...), Solaris (OpenCSW), and so on. Also, Wikipedia [1][2] uses the term "package management systems", so let's use that's term. [1] https://en.wikipedia.org/wiki/RPM_Package_Manager [2] https://en.wikipedia.org/wiki/APT_(software) 2021-01-26 Bruno Haible <br...@clisp.org> doc: More precise wording. Reported by Reuben Thomas <r...@sc3d.org> in <https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00300.html>. * doc/relocatable.texi (Enabling Relocatability): Talk about package management systems in general. diff --git a/doc/relocatable.texi b/doc/relocatable.texi index d2b5033..f8eec1e 100644 --- a/doc/relocatable.texi +++ b/doc/relocatable.texi @@ -8,7 +8,8 @@ and have it work correctly (including i18n). So many users need to go through @code{configure; make; make install} with all its dependencies, options, and hurdles. -Red Hat, Debian, and similar package systems solve the ``ease of +Most package management systems, that allow the user to install +pre-built binaries of the packages, solve the ``ease of installation'' problem, but they hardwire path names, usually to @file{/usr} or @file{/usr/local}. This means that users need root privileges to install a binary package, and prevents installing two
