[opensuse-packaging] hplip dependencies: Requires vs. Recommends, python3-scikit-image
The scanning tools in the hplip package need "python3-scikit-image" for full functionality. That dependency is currently missing, and I'm considering adding it. I can't test this well myself because I'm missing suitable hardware. But the way hplip typically deals with missing dependencies at runtime, users will at best see a generic or misleading error message; more likely, some options will simply be missing or greyed out for no obvious reason. My problem is that "python3-scikit-image" pulls in a whole bunch of additional python packages (155 packages / 576 MiB on my TW system, which already had quite a bit of python stuff installed). Installing it with --no-recommends pulls in "only" 8 packages / 156 MiB. I'm now wondering if I should add this requirement to hplip as "Requires" or "Recommends". I wouldn't normally classify it as a hard requirement, as it's only needed for special functionality provided only with special HP ScanJet models (e.g. "punchhole removal"). From that point of view, it's clearly a "recommends" or even a "suggests". However, if I use "recommends", people using "--no-recommends" won't get the scikit stuff at all and miss functionality in obscure ways, whereas people using "--recommends" would get the full 155 recommended packages. If I use "Requires", OTOH, the result with "--recommends" would be the same, but with "--no-recommends", users would "only" need to install the 8 packages that python3-scikit-image pulls in hard, and most likely the required run-time functionality would be available to them. The latter would be my personal preference as a user (well - for my printer model the extra functionality isn't offered anyway, so for me personally, using "suggests" is actually the best). Another option would be to separate out these new scanning tools "hp- scan" and "hp-uiscan" into an extra package and add the requirements there. I don't think they have many users yet, as I expect most users to simply use the usual SANE tools, xsane and scanimage. But that's just a guess. But if I do this, I have the same problem, because "hplip" would need to have a "Recommends: hplip-hpscan". Hints and opinions welcome. Martin
On Mon, Aug 26, 2019 at 6:54 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
The scanning tools in the hplip package need "python3-scikit-image" for full functionality. That dependency is currently missing, and I'm considering adding it. I can't test this well myself because I'm missing suitable hardware. But the way hplip typically deals with missing dependencies at runtime, users will at best see a generic or misleading error message; more likely, some options will simply be missing or greyed out for no obvious reason.
My problem is that "python3-scikit-image" pulls in a whole bunch of additional python packages (155 packages / 576 MiB on my TW system, which already had quite a bit of python stuff installed). Installing it with --no-recommends pulls in "only" 8 packages / 156 MiB.
I'm now wondering if I should add this requirement to hplip as "Requires" or "Recommends". I wouldn't normally classify it as a hard requirement, as it's only needed for special functionality provided only with special HP ScanJet models (e.g. "punchhole removal"). From that point of view, it's clearly a "recommends" or even a "suggests".
However, if I use "recommends", people using "--no-recommends" won't get the scikit stuff at all and miss functionality in obscure ways, whereas people using "--recommends" would get the full 155 recommended packages. If I use "Requires", OTOH, the result with "--recommends" would be the same, but with "--no-recommends", users would "only" need to install the 8 packages that python3-scikit-image pulls in hard, and most likely the required run-time functionality would be available to them. The latter would be my personal preference as a user (well - for my printer model the extra functionality isn't offered anyway, so for me personally, using "suggests" is actually the best).
Another option would be to separate out these new scanning tools "hp- scan" and "hp-uiscan" into an extra package and add the requirements there. I don't think they have many users yet, as I expect most users to simply use the usual SANE tools, xsane and scanimage. But that's just a guess. But if I do this, I have the same problem, because "hplip" would need to have a "Recommends: hplip-hpscan".
Would conditional Requires work here? Requires: (python3-scikit-image if foo) Obviously, you replace foo with some actually common package that would naturally require hplip to have scanning working... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2019-08-26 at 07:00 -0400, Neal Gompa wrote:
Would conditional Requires work here?
Requires: (python3-scikit-image if foo)
Obviously, you replace foo with some actually common package that would naturally require hplip to have scanning working...
... and I was about to say that I had spent two hours searching for package "foo" :-) No, unfortunately, I can't think of such a package (we already have hplip-sane, but that's the SANE _backend_, whereas we are talking about front-end functionality here). hplip is pretty much a leaf package. And this feature is about special post-processing functionality, which would normally be done manually. Some users will find it handy; many probably won't care. As I said, we could create a hplip-hpscan sub-package, which only those users would install that actually use "hp-scan" or "hp-uiscan". Martin
Martin Wilck schrieb:
[...] I'm now wondering if I should add this requirement to hplip as "Requires" or "Recommends". I wouldn't normally classify it as a hard requirement, as it's only needed for special functionality provided only with special HP ScanJet models (e.g. "punchhole removal"). From that point of view, it's clearly a "recommends" or even a "suggests". [...] Another option would be to separate out these new scanning tools "hp- scan" and "hp-uiscan" into an extra package and add the requirements there.
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK. cu Ludwig [1] https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 247165 (AG München) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2019-08-26 at 17:01 +0200, Ludwig Nussel wrote:
Martin Wilck schrieb:
[...] I'm now wondering if I should add this requirement to hplip as "Requires" or "Recommends". I wouldn't normally classify it as a hard requirement, as it's only needed for special functionality provided only with special HP ScanJet models (e.g. "punchhole removal"). From that point of view, it's clearly a "recommends" or even a "suggests". [...] Another option would be to separate out these new scanning tools "hp- scan" and "hp-uiscan" into an extra package and add the requirements there.
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK.
That would certainly be nice if we could get it right, but that won't be easy (in particular with very limited testing opportunities). The way I read the code, it's just certain ScanJet models (not the common all-in-one models). https://sourceforge.net/p/hplip/news/2018/12/hplip-31812-release-notes/ says:
User can use ScanJet feature by using hp-uiscan tool Following features are introduced for ScanJet: - PunchHole Removal - ColorDropOut/ColorRemoval - Background Noise Removal - Background Color Removal - BMP File format Support - Searchable PDF - Smaller file size for PDF and JPEG
So it's for certain _scanners_ only (not printers), and also only if people want these extra features. I'd rather postpone this HW-detection feature to some later time. Currently I my focus is to create a package that is suitable for Leap 15.2 submission. Thanks, Martin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2019-08-26 at 17:50 +0200, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:01 +0200, Ludwig Nussel wrote:
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK.
That would certainly be nice ...
I forgot the most important aspect, printers and scanners are often connected via the network and thus not reliably detectable. So, I don't think this would be worth the effort. Martin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2019-08-26 at 17:50 +0200, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:01 +0200, Ludwig Nussel wrote:
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK.
That would certainly be nice ...
I forgot the most important aspect, printers and scanners are often connected via the network and thus not reliably detectable. So, I don't think this would be worth the effort. Martin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 8/28/19 5:41 PM, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:50 +0200, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:01 +0200, Ludwig Nussel wrote:
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK.
That would certainly be nice ...
I forgot the most important aspect, printers and scanners are often connected via the network and thus not reliably detectable. So, I don't think this would be worth the effort.
If your like me and even if its not connected to the network you generally leave it off until you actually use it which would likely lead to a change in zypper behavior on the one time you zypper up or dup with the printer switched on. So I tend to agree this is not a great idea for USB plug and play devices (unless someone wants to write a daemon to detect when a device is plugged in for the first time and suggest installing the driver through packagekit or something the way Windows has done for years) -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Simon Lees schrieb:
On 8/28/19 5:41 PM, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:50 +0200, Martin Wilck wrote:
On Mon, 2019-08-26 at 17:01 +0200, Ludwig Nussel wrote:
For hardware specific packages there are special modalias Supplements. So if libzypp detects matching hardware it would automatically pull in those packages. There are also special tags for printer drivers¹ (in case there are such scanners attached to printers). Support for that was never properly implemented in openSUSE though AFAIK.
That would certainly be nice ...
I forgot the most important aspect, printers and scanners are often connected via the network and thus not reliably detectable. So, I don't think this would be worth the effort.
If your like me and even if its not connected to the network you generally leave it off until you actually use it which would likely lead to a change in zypper behavior on the one time you zypper up or dup with the printer switched on. So I tend to agree this is not a great idea for USB plug and play devices (unless someone wants to write a daemon to detect when a device is plugged in for the first time and suggest installing the driver through packagekit or something the way Windows has done for years)
The Fedora page I linked describes exactly that. So I suppose the work was done long ago. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 247165 (AG München) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 2019-08-28 at 11:59 +0200, Ludwig Nussel wrote:
The Fedora page I linked describes exactly that. So I suppose the work was done long ago.
I digged a little more. Indeed we used to have the dependency generator script "/usr/lib/rpm/postscriptdriver.prov" in the python-cups package. Therefore all printer drivers have had BuildRequires on python-pycups for a long time (https://bugzilla.novell.com/show_bug.cgi?id=735865). If all went well, the script would create automatic Provides: tags for printers from PPD or cups .drv files included in a package. Unfortunately, with the replacement of python-cups by python-pycups, this got forgotten, and the file is not provided any more. So we basically lost this functionality (the packaging part at least) with SLE/Leap 15. I've created sr#726827 to re-introduce this file. As a next step, printer drivers would need to BuildRequire the "cups-rpm-helper" package rather than python-cups. (I have tried to simply add the file to python3-cups, but I couldn't get it right, so I created a subpackage). Regards, Martin
participants (6)
-
Ludwig Nussel -
Martin Wilck -
Martin Wilck -
Martin Wilck -
Neal Gompa -
Simon Lees