Description of problem: Snippet of cups.spec: %define cups_serverbin %{_exec_prefix}/lib/cups {...} install -c -m 755 %{SOURCE9} $RPM_BUILD_ROOT%{cups_serverbin}/filter/textonly Should it be "lib64" instead of "lib" in case of x86_64 architecture?! I am creating a spec file for SpliX that provides some cups drivers for printers using SPL (Samsung Printer Language) from Samsung itself and several other companies. So, I would have to use an hard coded path as well there, cause %{_libdir} value is ".../usr/lib64". Version-Release number of selected component (if applicable): cups-1.4.6-1.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Filters and PPD files must be installed always in /usr/lib, not in /usr/lib64 for x86_64. Expected results: Individual path depending on architecture. Similiarities to the architecture depending value of %{_libdir} . Additional info: rpmlint does not like this in splix.spec: %files %{_prefix}/lib/cups/filter/pstoqpdl %{_prefix}/lib/cups/filter/rastertoqpdl
(In reply to comment #0) $ cups-config --serverbin /usr/lib/cups
/usr/lib/cups is correct, even on x86_64. It is not used for putting shared objects in but for executables, and multilibbing works correctly in that situation. It's more of a libexec-style usage, but we use lib for compatibility with 3rd party drivers (at upstream request).
I could possibly put a comment in cups.spec why we use hard-coded %{_exec_prefix}/lib and not %{_libdir} or %{_libexecdir} (also bug #225670, comment #2).
I was also thinking about packaging Splix, because I have QPDL (SPL2) printer. But RPMs from http://www.openprinting.org/driver/splix/ work without any problems in all Fedora releases so I abandoned that idea. But if you need someone to review your package, count on me.
That's a really good idea with openprinting, but which package should the normal user choose from the different LSB version, how should he/she know? And yes, please add a comment in the cups.spec file. It's just confusing for packagers of new drivers, without any given reason.
(In reply to comment #5) Okay, the linuxprinting.org package works for me. There is a yum repository available. http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/driverpackages#Installation_with_the_package_tool_of_your_distribution_and_automatic_updates (scroll down to see the content of the desired repo file)
(In reply to comment #6) Hi Jiri, I encountered that the linuxprinting.org package installs everything under /opt. That is no good way in trying to be conform with LSB. I am currently working on an official splix.spec file for an official Fedora package. Though, the big image compression library is somehow proprietary, but optional, and available only via rpmfusion. So probably we need two packages, but I do not know if that library is needed at all - my printer works without it, anyways. Further, I would need some help to compile those .tex files (propably to PDF) in doc/ for the doc sub-package.
(In reply to comment #7) > Though, the big image compression library is somehow proprietary, but optional, and > available only via rpmfusion. So probably we need two packages, but I do not > know if that library is needed at all - my printer works without it, anyways. Xerox Phaser 3117 was also working without JBIG library so I think we can start without it. > Further, I would need some help to compile those .tex files (propably to PDF) > in doc/ for the doc sub-package. I can't find any .tex files in splix-2.0.0.tar.bz2.
(In reply to comment #8) .tex files are in the svn's doc/ branch… https://splix.svn.sourceforge.net/svnroot/splix/doc/specs/ https://splix.svn.sourceforge.net/svnroot/splix/doc/specs-en/
http://sourceforge.net/projects/splix/files/doc/1.0/specs-en.pdf
Due to bug #753641, comment #12 I've been again thinking about shipping SpliX in Fedora. I've been checking the JBIG problem again and this is what I've discovered: There's a jbigkit package in rpmfusion-free. Even it's possible to build SpliX without JBIG support most likely some printers (no idea how many of them) won't work then. http://www.cl.cam.ac.uk/~mgk25/jbigkit/ says, that: Patents: Annex E of the JBIG1 standard lists a number of patents that might have been applicable to implementations. These have now expired worldwide, with the exception of one single patent that remains in force only in the United States until 4 April 2012. JBIG-KIT comes without any patent licence. So it seems that in April 2012 we'll be able to ship jbigkit with Fedora and therefore also SpliX with JBIG support. Hurah ! :-) It also seems that SpliX upstream is quite active (though last version 2.0.0 was released in February 2009). Till Kamppeter is actively commiting fixes and support for new printers so we can expect new version sometimes.
(In reply to comment #11) Thank you for the summary. An official package in Fedora would be appreciated! :) Nevertheless, I can also go with the package from OpenPrinting.
Raphael, could you attach the spec file you spoke about in the description of this bug ? I can either take it over from you, continue where you ended and submit it for Package Review or make an informal review of it before you submit it for Package Review yourself. What sounds better to you ? If you don't have it anymore, I'll start from scratch.
I actually went on and created the spec file from scratch. Hope you don't mind. I'll be glad if you could try the SRPM mentioned in Package Review (bug #755069).