Summary: | net-print/hplip update should trigger update of net-print/hplip-plugin | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexey Shvetsov <alexxy> |
Component: | Current packages | Assignee: | Printing Team <printing> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | billie, chain, chewi, creideiki+gentoo-bugzilla, gentoo, sam, sandyvujakovicj, xavier.miller, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 729012 |
Description
Alexey Shvetsov
![]() ![]() That would require a plugin use flag for hplip which always pulls in the same version of the plugin. In turn the dependency on hplip has to be removed from the plugins. I know this would solve some problems. This needs to be coordinated however as I maintain hplip but not the plugins. So every time there is a version bump for hplip the plugins need to be bumped before. (In reply to Daniel Pielmeier from comment #1) > That would require a plugin use flag for hplip which always pulls in the > same version of the plugin. In turn the dependency on hplip has to be > removed from the plugins. > > I know this would solve some problems. This needs to be coordinated however > as I maintain hplip but not the plugins. So every time there is a version > bump for hplip the plugins need to be bumped before. This does seem obscure, and even more so that the two packages have entirely separate maintainers. I've seen elsewhere ebuilds that require matching versions of dependencies, so this is trivial to add; but there might need to be some clever USE-conditional 'fu' to overcome eg. license restrictions too. Not insurmountable though, right? (In reply to Michael 'veremitz' Everitt from comment #2) > > This does seem obscure, and even more so that the two packages have entirely > separate maintainers. I've seen elsewhere ebuilds that require matching > versions of dependencies, so this is trivial to add; but there might need to > be some clever USE-conditional 'fu' to overcome eg. license restrictions too. > Not insurmountable though, right? This is all doable. If I add the use flag I just always have to wait for the plugin to be bumped first. Without looking closer into it I also do not see a problem with licensing. Anybody who wants to use the plugin just has to accept the plugins license. Actually however hplip-plugin currently has no maintainer. If this doesn't not change it should flagged maintainer-needed. It was initially added by proxy. After 6 month it was abandoned and Manuel Rüger (mrueg) from the printing team stepped up maintaining it. He also added the printing team which he was a member of, instead of himself. In my opinion adding the team even when being a member of does not make sense if I am the only one taking care of the package. Manuel is now retired which makes the plugin unmaintained. So if nobody from the printing team or somebody else steps up to maintain it I will not add a dependency on it. @James: Sorry for CC'ing you. I recognized you recently bumped the plugin two times. Maybe you have an interest in actually maintaining it? If yes I am sure we can come up with a solution that suits everybody. I mentioned it often before that first I can not maintain it because I do not have a printer requiring the plugin and thus can not test it properly. Second I don't really like this binary, proprietary stuff which only causes trouble. Unfortunately HP continues to produce printers who require the plugin and quite a few buy them believing in good Linux support but oversee the binary plugin or just are ignorant to it. At some time I was considering proxy maintenance but with the previous experience it seams even more hassle than maintaining it directly. (In reply to Daniel Pielmeier from comment #3) > (In reply to Michael 'veremitz' Everitt from comment #2) > > > > This does seem obscure, and even more so that the two packages have entirely > > separate maintainers. I've seen elsewhere ebuilds that require matching > > versions of dependencies, so this is trivial to add; but there might need to > > be some clever USE-conditional 'fu' to overcome eg. license restrictions too. > > Not insurmountable though, right? > > This is all doable. If I add the use flag I just always have to wait for the > plugin to be bumped first. Without looking closer into it I also do not see > a problem with licensing. Anybody who wants to use the plugin just has to > accept the plugins license. > > Actually however hplip-plugin currently has no maintainer. If this doesn't > not change it should flagged maintainer-needed. It was initially added by > proxy. After 6 month it was abandoned and Manuel Rüger (mrueg) from the > printing team stepped up maintaining it. He also added the printing team > which he was a member of, instead of himself. In my opinion adding the team > even when being a member of does not make sense if I am the only one taking > care of the package. Manuel is now retired which makes the plugin > unmaintained. So if nobody from the printing team or somebody else steps up > to maintain it I will not add a dependency on it. > If it helps, I can co-maintain, and it is my full intention to apply for devship later this year. See below. > @James: Sorry for CC'ing you. I recognized you recently bumped the plugin > two times. Maybe you have an interest in actually maintaining it? If yes I > am sure we can come up with a solution that suits everybody. > > I mentioned it often before that first I can not maintain it because I do > not have a printer requiring the plugin and thus can not test it properly. > Second I don't really like this binary, proprietary stuff which only causes > trouble. Unfortunately HP continues to produce printers who require the > plugin and quite a few buy them believing in good Linux support but oversee > the binary plugin or just are ignorant to it. > > At some time I was considering proxy maintenance but with the previous > experience it seams even more hassle than maintaining it directly. I have a couple of HP printers (inkjet and laser) which are my daily drivers here, and being networked and MFP they are quite useful. Also, they require the binary blobs (which I'm ambivalent about) for network scanning and other ancillary functions, but I've been very happy with their functionality. I also have a reasonable access to the principle arches in active use today - x86_64, arm[64], and latterly a headless powerpc64 VM which I can use for test and compilation, which should help you out there too (the ppc doesn't have direct access to the printers, although conceivably I could tunnel a port!) How does that sound? (In reply to Michael 'veremitz' Everitt from comment #4) > > How does that sound? Okay, lets try that! How about you providing a pull request for hplip-plugin-3.20.5 without the dependency on hplip? I will then add the dependency plugin to hplip. No worries about the ping as I do use this. It sounds like you have this in hand now but I can also help if required. I have a very reliable HP Color LaserJet MFP M180n, which requires the plugin for the scanner. I don't scan very often but I have bumped this as required up till now. Blobs do suck but I was still impressed that HP bothered to provide one for 32-bit ARM, which is what I use this on. (In reply to James Le Cuirot from comment #6) > No worries about the ping as I do use this. It sounds like you have this in > hand now but I can also help if required. I have a very reliable HP Color > LaserJet MFP M180n, which requires the plugin for the scanner. I don't scan > very often but I have bumped this as required up till now. Blobs do suck but > I was still impressed that HP bothered to provide one for 32-bit ARM, which > is what I use this on. Michael and James, what about you taking care of hplip-plugin? At least you have the hardware to test! I continue with hplip itself and we coordinate each other with version bumps? (In reply to Daniel Pielmeier from comment #7) > (In reply to James Le Cuirot from comment #6) > > No worries about the ping as I do use this. It sounds like you have this in > > hand now but I can also help if required. I have a very reliable HP Color > > LaserJet MFP M180n, which requires the plugin for the scanner. I don't scan > > very often but I have bumped this as required up till now. Blobs do suck but > > I was still impressed that HP bothered to provide one for 32-bit ARM, which > > is what I use this on. > > Michael and James, what about you taking care of hplip-plugin? At least you > have the hardware to test! I continue with hplip itself and we coordinate > each other with version bumps? I'm down with that .. and James can proxy commits if needed until I have +w. We're even in the same timezone! :P :thumbsup: Yep, works for me. Just ping one or both of us and we'll figure it out. I'll test and bump it tomorrow and add ourselves as maintainers. |