Bugzilla – Bug 142004
move cups-config to the cups package
Last modified: 2015-02-26 14:39:38 UTC
I was informed by a customer that the installation of a third-party driver package failed on his x86_64 system because a filter was installed in /usr/lib/cups/filter/ instead of /usr/lib64/cups/filter/ Reason: cups-config is not available in a default installation. But the third-party driver package would need it to determine the CUPS binary directory where filters and backends must be stored. On i386 it works because it uses /usr/lib/cups/ as fallback but on x86_64 this fallback is wrong.
I'm not happy with this proposal. I think it's more related to package "cups-dev" than any other. Want to sleep a night over it, for final decision.
moved it into main package. fixed in next version.
ARGS, this breaks the build of ghostscript-library which depends on cups-config.
Couldn't we inform the vendor to install cups-devel for installation of the driver or to use a different test? This change also breaks the samba builds as we rely on cups-config being in the cups-devel package. The current solution will provide use more pain. Please revert it and inform the third party vendor on how to fix his install.
Klaus: Your comment #1 is full correct. cups-config belons to the cups-devel package. And moving the file will create more problems for us and other vendors than providing information to the vendor how to fix _his_ particular problem.
how about moving cups-config into the cups-libs package. the devel package should require the cups-libs rpm. -> build system issues fixed. additionally the customer will get his fix too. the cups main package requires cups-libs -> cups-config is available for the customer everyone would be happy.
Got catch Marcus! Klaus: I've copied a cuos packaged with the changes suggested by Marcus to stable. It's still your decision if you prefer cups-devel.
cups-libs seems to work now. closing it.
This breaks gutenprint build! https://sourceforge.net/support/tracker.php?aid=1504268 If a *-config is installed, related headers have to be installed aswell! I did not have cups-devel installed when I configured gutenprint. Configurations usually tells me what I am missing. Now I had to track it down from compilation error messages...
Thanks, for pointing this out. But I have doubts that your assumption is true. Please tell us, which standard requires that "if a [cups]-config is installed, related headers have to be installed as well!" ??? If this is true, then cups-config has design flaw: it's used to give the user/system more information about the cups system configuration than just about devel related tasks. Therefore I think that cups-config is no longer part in package cups-devel, is the correct decision. If a package relies on some specific include files, like gutenprint, then it should test for them in "configure" phase, and not stop compilation later. --> this is my favored solution.
Great! Could you please convince 'rlk' about that since he closed my gutenprint report! "Gutenprint relies on cups-config to tell it how to compile the CUPS driver, which is the normal protocol for this purpose. It's behaving as intended, so I am closing this."
started discussion at sf.net
A workaround using "Extras install all matching -devel packages" is quite nice! Once you like to start developing use it. It will take some disk space but is worth it! Could it be made sticky? Then a simple question during install: "Will this computer be used for software development?" will cause all base -devel packages to be installed. And that matching -devel packages will be installed in future.
*** Bug 919732 has been marked as a duplicate of this bug. ***