Jump to content
Read the Funtoo Newsletter: Summer 2023 ×
  • 0

running lprng: but foomaticdb pulls in cups


xkbc

Question

Hi,
 
I am running lprng with this use flags at the moment:

net-print/lprng-3.8.35-r2  USE="nls ssl -foomaticdb -kerberos"

Now I need to add the foomaticdb use flag so that I can run my printer with lprng - but then I get a block:

Calculating dependencies... done!
[ebuild  N     ] app-text/qpdf-5.1.2:0/13  USE="-doc -examples -static-libs {-test}" 7,485 kB
[ebuild  N     ] app-text/enscript-1.6.6  USE="nls -ruby" 1,300 kB
[ebuild  N     ] net-print/foomatic-filters-4.0.17-r1  USE="dbus -cups" 261 kB
[ebuild  N     ] net-print/cups-1.7.3  USE="X acl dbus pam python ssl threads -debug -gnutls -java -kerberos -lprng-compat (-selinux) -static-libs -sy
stemd -usb -xinetd -zeroconf" LINGUAS="-ca -es -fr -it -ja -pt_BR -ru" PYTHON_SINGLE_TARGET="python2_7 (-python2_6)" PYTHON_TARGETS="python2_7 (-pytho
n2_6)" 8,587 kB
[ebuild   R    ] app-text/ghostscript-gpl-9.14  USE="X cups* dbus djvu idn -bindist -gtk -static-libs" LINGUAS="de -ja -ko -zh_CN -zh_TW" 0 kB
[ebuild  N     ] net-print/cups-filters-1.0.54  USE="dbus foomatic jpeg png tiff -perl -static-libs -zeroconf" 1,284 kB
[ebuild  N     ] net-print/foomatic-db-engine-4.0.11  352 kB
[ebuild  N     ] net-print/foomatic-db-4.0.20140105  37,935 kB
[ebuild   R    ] net-print/lprng-3.8.35-r2  USE="foomaticdb* nls ssl -kerberos" 0 kB
[blocks B      ] >=net-print/cups-1.6.2-r4[-lprng-compat] (">=net-print/cups-1.6.2-r4[-lprng-compat]" is blocking net-print/lprng-3.8.35-r2)
[blocks B      ] >=net-print/cups-filters-1.0.43-r1[foomatic] (">=net-print/cups-filters-1.0.43-r1[foomatic]" is blocking net-print/foomatic-filters-4
.0.17-r1)
[blocks B      ] net-print/lprng ("net-print/lprng" is blocking net-print/cups-1.7.3)
[blocks B      ] net-print/foomatic-filters ("net-print/foomatic-filters" is blocking net-print/cups-filters-1.0.54)

Total: 9 packages (7 new, 2 reinstalls), Size of downloads: 57,201 kB
Conflict: 4 blocks (4 unsatisfied)
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
app-text/ghostscript-gpl:0
  (app-text/ghostscript-gpl-9.14::gentoo, ebuild scheduled for merge) pulled in by
    app-text/ghostscript-gpl[cups] required by (net-print/cups-1.7.3::gentoo, ebuild scheduled for merge)
  (app-text/ghostscript-gpl-9.14::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

As soon I enable the foomaticdb use flag of lprng, the ebuild foomatic-db-engine pulls cups in by:

..
DEPEND="net-print/cups"
..

That makes no sense to me as the foomatic drivers are especially made the way that they can be used by any printing system (see also http://www.linuxfoundation.org/collaborate/workgroups/openprinting/databasefoomatic#Using_Foomatic_with_a_particular_printer_and_spooler ).
 
Can this be fixed or is here a bug reported needed?
 
Thanks
 
 

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

  • 0

UPDATE:
 
I found that this dependency was done by a wrong assumption:

The foomatic filters, an awesome printer driver system, originally supported not just CUPS but also LPRng, LPD, and many other prehistoric printing systems. Turns out, every backend except cups is now unmaintained. As a result, after a Google summer of code project, the actual filter binary is now upstream moving into cups-filters, to have a more active development and be perfectly integrated into the CUPS printing system. (Yes this means foomatic support for LPRng will not see further updates and may have to go away one day in the future due to bitrot.)

(from http://dilfridge.blogspot.de/2013/12/foomatic-is-moving-into-cups-filters.html )
 
But lprng is still maintained: Last stable: 19 Mar 2014 (For LPRng-3.8.35) (from http://lprng.com ).

 

And lprng is also still maintained by foomatic (see http://www.linuxfoundation.org/search/node/foomatic and http://www.linuxfoundation.org/collaborate/workgroups/openprinting/databasefoomatic#Using_Foomatic_with_a_particular_printer_and_spooler ).

 

How to notify the ebuild maintainer that this foomatic and cups bundling is based on the wrong assumption that lprng is not maintained? With the goal to get back lprng with foomatic. :)

Link to comment
Share on other sites

  • 0

Hi Dantrell,

 

thanks. I updated my portage today and tried to emerge lprng with foomaticdb but cups is still pulled in:

[ebuild  N     ] net-print/lprng-3.8.35-r2  USE="foomaticdb nls ssl -kerberos" 12,220 kB
[ebuild  N     ]  net-print/foomatic-db-4.0.20140105  37,935 kB
[ebuild  N     ]   net-print/foomatic-db-engine-4.0.11  352 kB
[ebuild  N     ]    net-print/cups-1.7.5-r2  USE="X acl dbus lprng-compat pam python ssl threads -debug -gnutls -java -kerberos (-selinux) -static-libs -systemd -usb -xinetd -zeroconf" LINGUAS="de -ca -cs -es -fr -it -ja -pt_BR -ru" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 8,588 kB

There is still a hardwired dependency to cups via foomatic-db-engine. I also found a couple of application packages that have unnecessary hardcoded dependency on cups (like scribus). But I like to do the test with a working lprng+foomatic installation.

 

Did I anything wrong to still get the cups dependency?

Link to comment
Share on other sites

  • 0

It would require forking quite a few packages to properly unbundle cups and I'm not sure that's a good idea. I no longer have the time to do it now anyway so what I did do was resolve the blocker.

That said, lprng still pulls in cups if you enable the foomatfcidb USE flag. But even you changed that ebuild, foomatic-db-engine also pulls in cups.

You may want to try your luck contacting the responsible team on Gentoo upstream.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...