Hplip for Rocky 8

Rocky Linux Help & Support
1

I have an HP Laserjet Pro M148 multifunction printer/scanner that requires an updated hplip. There is very little out there on how to do this, but I got it to work and want to share the process that worked for me.

  1. Download the tarball from here. Get the advanced tarball from the bottom. As of this writing, the link is https://sourceforge.net/projects/hplip/files/hplip/3.23.5/hplip-3.23.5.tar.gz/download.

  2. Untar it into a folder and move to that folder.

  3. Install the hplip packages to get all the dependencies:
    sudo dnf install hplip hplip-gui

  4. Remove the hplip files, but leave the dependencies:
    sudo rpm -e --nodeps hplip hplip-gui hplip-libs hplib-common

  5. Add other needed dependencies for building. Note: This is my dev box, so if you run the configure command below and it breaks, you probably are missing a package (i.e.: libusb-devel) that I have already installed. Just search for that devel package and install it, too:
    sudo dnf install net-snmp-devel sane-backends-devel

  6. Configure the build for Qt5:
    ./configure --with-hpppddir=/usr/share/cups/model/HP --libdir=/usr/lib64 --prefix=/usr --disable-qt4 --enable-qt5 --disable-libusb01_build --enable-doc-build --enable-cups-ppd-install --disable-foomatic-drv-install --disable-foomatic-ppd-install --disable-hpijs-install --disable-udev_sysfs_rules --disable-policykit --disable-cups-drv-install --enable-hpcups-install --enable-network-build --enable-dbus-build --enable-scan-build --enable-fax-build

  7. Make and install:
    make sudo make install

  8. Run hp-setup.

Happy printing (and scanning!)

2

You’re breaking the rpm based system that EL is built around.

hplip-3.23.5 is available as a rpm for Fedora, so you should download the src rpm for that and compile it on your Rocky system. Since this version of hplip complies on EL8 (you’ve done that so we know it works) there shouldn’t be much difficulty compiling from a srpm instead.

Any time you’re using a rpm command that includes --nodeps be aware that 99.999% of of the time what you’re trying to do is a really bad idea and there’s a better way to get it done.

1 Like
3

I would also like to add my two Peneth to Franks answer.

taking any of the readily available tar balls from the linux world and running ./configure, make, make install on them is like a seagull crapping all over your filesystem, and this is the same weather using dpkg on the other side of the fence or rpm on this side.
The packaging system is there to ensure the integrity of your operating system.

Any fedora/rhel derived package can be built using rpm-build and its associated tools.

you may have to choose the version of the srpm carefully to fit in with the age of the core of the release you are compiling on.

what nodeps does its ignores the dependencies defined in the rpm, so if it says requires lib.ver1.subversion2 and you dont have that version it maybe that the app wont run, but it maybe something the rpm depends on to install or remove and therefore the install will fail and it wont be able to uninstall what it has so far.

just like the seagull example above.

if you are going to use a tarball, always add --prefix=/opt/appname to the configure command to keep it away from the core directories.

regards peter

4

More on the theme:

  • When you run dnf, it keeps history of transactions for you to seek “When did I?”, and to undo or redo a transaction. Calls to rpm do not add to that history
  • Rather than actually installing the hplip hplip-gui hplip-libs hplib-common one can figure out (for example, with dnf repoquery, or by install followed by remove --noautoremove dnf transactions) what other packages they would pull in and install those directly
  • The rpm -e --nodeps is not about packages that hplip did pull in, but about packages that require hplip. Like these:
$ dnf rq --whatrequires hplip
$ dnf rq --whatrequires hplip-gui
$ dnf rq --whatrequires hplip-libs
hplip-0:3.21.2-6.el9.alma.x86_64
libsane-hpaio-0:3.21.2-6.el9.alma.i686
libsane-hpaio-0:3.21.2-6.el9.alma.x86_64
$ dnf rq --whatrequires hplip-common
hplip-libs-0:3.21.2-6.el9.alma.i686
hplip-libs-0:3.21.2-6.el9.alma.x86_64

In other words: libsane-hpaio (and whatever requires it).

Overall, one does not inject source builds into the mids of files that package management governs and replacement of (particularly core) system packages (with RPM-packages of your own) is not the “Enterprise Linux way” most of the time.

5

Yes, I realize that the package manger is better, however the current version is insufficient for many of the newer multi-function devices. Deploying an updated RPM in a way that is both accessible and maintainable is beyond my time constraints at the moment. (I have contributed to several opensource projects and know the workload - it is not trivial).

On the other hand, someone like me, who needs it to work and needs it now can use this method to get their desktop to print and scan, and I think that is a good thing.

6

I really don’t see it as being any more difficult to deploy and maintain an updated rpm than your solution. In fact, it’s far easier to do both of those things with a rpm for the reasons detailed by me and others above.

Remember that you don’t have to make a publicly available rpm here if you don’t want to. It’s perfectly legitimate to compile and install a rpm for your own use.