Package Details: hplip-plugin 3.25.2-1

Git Clone URL: https://aur.archlinux.org/hplip-plugin.git (read-only, click to copy)
Package Base: hplip-plugin
Description: Binary plugin for HPs hplip printer driver library
Upstream URL: https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html
Keywords: fax hp printer scanner
Licenses: LicenseRef-HPLIP-LICENSE
Submitter: pyropeter
Maintainer: ZhangHua
Last Packager: ZhangHua
Votes: 403
Popularity: 0.85
First Submitted: 2010-12-21 00:32 (UTC)
Last Updated: 2025-04-05 00:57 (UTC)

Pinned Comments

carsme commented on 2024-01-15 16:53 (UTC) (edited on 2024-02-04 14:15 (UTC) by carsme)

Hey, I've adopted this package and applied some of the suggestions:

  • Add missing dependencies, notably libusb-compat and sane (cred @ZhandHua).
  • Depend on exact version of hplip (cred @jsn42).

In addition, the PGP-signature of the artifact is now checked, which means you need to fetch upstream's key:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 4ABA2F66DBD5A95894910E0673D770CDA59047B9

Unfortunately, I have no HP printer at home so my testing ability is limited to running hp-diagnose_plugin. If someone has better opportunity to test and is interested in maintaining, let me know and I'll handover the package or add you as a co-maintainer. Cheers!

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 38 Next › Last »

argymeg commented on 2020-10-26 13:53 (UTC) (edited on 2020-10-26 13:54 (UTC) by argymeg)

@pieplu for better or for worse, your assumption is not correct - pacman always upgrades packages to their latest version, regardless of how they were installed. Partial upgrades are explicitly unsupported in Arch and packages in the official repos always assume all other packages are at the latest version, and mutually dependent packages like this would always be upgraded together - unfortunately with the AUR things aren't that simple.

In these cases manually downgrading hplip is probably the easiest way to go about it, although there's always a risk, however small, that the simultaneous upgrade of some other package will no longer allow the older hplip to work. Another perhaps more "correct" option, since the new hplip-plugin will have been released upstream at the same time as the new hplip, is to manually update the hplip-plugin PKGBUILD and install the latest version.

pieplu commented on 2020-10-26 13:30 (UTC)

@argymeg Interesting that puts it in context, I wonder if the way hplip/hplip-plugin is installed will have an impact on dependency resolution. If we don't install hplip directly, but only hplip-plugin (which will solve the hplip dependency). I would have thought that with this procedure, even if hplip has a new version, since it is not directly in the system, but only because of hplip-plugin, which wants a specific version, pacman will not propose an update of it. Conversely, if you have installed hplip and then hplip-plugin, when a new version of hplip comes out, pacman will want to update it, and I guess it's normal that the update of hplip crashes since it breaks the dependency of hplip-plugin. Is my assumption correct? If so, maybe you should document this (don't install hplip directly). If not, it is annoying if it blocks the update of the whole system. And I guess the correct procedure would unfortunately be to manually downgrade hplip until hplip-plugin is updated.

argymeg commented on 2020-10-26 10:20 (UTC)

The version dependency used to be expressed more restrictively, similarly to this, and was changed several years ago (commit 98602ca43311). The issue then, which unless I'm much mistaken has now been reintroduced, was that any time hplip is upgraded in the repos, the system upgrade will fail. The user will then need to uninstall hplip-plugin, perform the upgrade, and reinstall hplip-plugin (provided the new version is available). I believe relaxing that requirement, so hplip can be upgraded at the risk of temporarily breaking printing was chosen as the lesser evil, and hasn't been a problem since given the usually prompt updates of this package. IMHO I preferred that behaviour, but it's up to the maintainer.

pieplu commented on 2020-10-22 21:04 (UTC)

Thanks @kaaposc for the explaination Thanks @andmars to change that, looks like it's working :)

kaaposc commented on 2020-10-22 14:04 (UTC)

@pieplu, it's called epoch: https://wiki.archlinux.org/index.php/PKGBUILD#epoch

➜  ~ pacman -Qi hplip
Name            : hplip
Version         : 1:3.20.9-1

As you can see hplip package has this epoch number specified before version string.

pieplu commented on 2020-10-22 13:53 (UTC)

@andmars thanks a lot for the update :)

I tryed too, and if we add "1:" before the package version, pacman found the dependencie, like that:

depends=("hplip=1:$pkgver")

I'm not a packager/expert, I really don't understant what is this "1:" before many package version, but it's looks like it's mandatory when = is used

<deleted-account> commented on 2020-10-22 05:22 (UTC)

Sorry for the late update this time!

@pieplu: removing ">" from the PKGBUILD runs (at least in my case) into:

==> Making package: hplip-plugin 3.20.9-1 (Thu 22 Oct 2020 07:21:04 AM CEST)

==> Checking runtime dependencies...

==> Installing missing dependencies...

error: target not found: hplip=3.20.9

==> ERROR: 'pacman' failed to install missing dependencies.

==> Missing dependencies:

-> hplip=3.20.9

==> Checking buildtime dependencies...

==> ERROR: Could not resolve all dependencies.