Created attachment 8976 [details] Causes mupdf to be installed to the DESTDIR directory, in case this is not root. Attempted to build mupdf as an RPM package, using the rpmbuild program, from the mupdf 1.1 tar.gz source tarball. Failed with permission errors on the install: unable to access /usr/man etc. Install command was: make prefix=/usr DESTDIR=${RPM_BUILD_ROOT} install The problem occurred because RPM packages are normally built under a non-root username and installed to a staging directory ('build root'), rather than / which is non-writable. This is specified by the DESTDIR variable as per the GNU Makefile manual. It is suggested that the mupdf Makefile should adopt this convention. The attached patch implements this.
(In reply to comment #0) <snipped> > Attempted to build mupdf as an RPM package, using the rpmbuild program, from > the mupdf 1.1 tar.gz source tarball. > > Failed with permission errors on the install: unable to access /usr/man etc. > Install command was: > > make prefix=/usr DESTDIR=${RPM_BUILD_ROOT} install <snipped> Is there any reason why existing RPM packaging is unsatisfactory? e.g. http://koji.fedoraproject.org/koji/packageinfo?packageID=11601 In any case, this kind of packaging issue seems more appropriate filed at say, https://bugzilla.redhat.com, or at least co-ordinated with a corresponding one.
(In reply to comment #1) > (In reply to comment #0) > <snipped> > > Attempted to build mupdf as an RPM package, using the rpmbuild program, from > > the mupdf 1.1 tar.gz source tarball. > > > > Failed with permission errors on the install: unable to access /usr/man etc. > > Install command was: > > > > make prefix=/usr DESTDIR=${RPM_BUILD_ROOT} install > <snipped> > > Is there any reason why existing RPM packaging is unsatisfactory? e.g. > http://koji.fedoraproject.org/koji/packageinfo?packageID=11601 This appears to be a Fedora package. I use openSUSE, and there seems to be no package in the openSUSE repositories. RPMs are sometimes portable between distributions, but often not - because of dependencies, among other things. > In any case, this kind of packaging issue seems more appropriate filed at say, > https://bugzilla.redhat.com, or at least co-ordinated with a corresponding one. I don't think it's really a packaging issue. It happened to occur when building a package, but I think the problem lies in the Makefile and would affect any build when /usr/... was not writable - of course, it's usually packagers who do this. I believe the small change I suggest, of using DESTDIR in accordance with the Make manual, would help to make the software more 'packager-friendly' and thus help encourage distros to include this very nice piece of software.