The bluez-utils package now has a CUPS backend for bluetooth printers. How should it be shipped?
The other CUPS backend which is shipped separate from CUPS itself is the one in samba-client. That one is just shipped in the samba-client RPM, and CUPS has a trigger script which makes a symlink to it from /usr/lib/cups/backend/ on installation of samba-client.
Is there a reason why the trigger is done that way round -- in the _cups_ specfile rather than the samba one? Or why we can't ship the extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts it directly into /usr/lib/cups/backend/ instead of making the symlink in a trigger script? Or any of the other possibilities?
On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:
The other CUPS backend which is shipped separate from CUPS itself is the one in samba-client. That one is just shipped in the samba-client RPM, and CUPS has a trigger script which makes a symlink to it from /usr/lib/cups/backend/ on installation of samba-client.
It was done this way by historical accident I think. However, it works now so there seems little point in changing it in that case.
Is there a reason why the trigger is done that way round -- in the _cups_ specfile rather than the samba one? Or why we can't ship the extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts it directly into /usr/lib/cups/backend/ instead of making the symlink in a trigger script? Or any of the other possibilities?
That certainly sounds like the best thing to do for new packages. It would be best to keep the knowledge of that backend in the package that provides it.
Tim. */
On Wed, May 19, 2004 at 03:42:48PM +0100, Tim Waugh wrote:
On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:
[...]
Is there a reason why the trigger is done that way round -- in the _cups_ specfile rather than the samba one? Or why we can't ship the extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts it directly into /usr/lib/cups/backend/ instead of making the symlink in a trigger script? Or any of the other possibilities?
That certainly sounds like the best thing to do for new packages. It would be best to keep the knowledge of that backend in the package that provides it.
I wasn't very clear here: I meant that any of these alternatives are better than putting it in cups.spec. :-)
Having a separate subpackage (which requires cups) sounds like the best approach.
Tim. */
On Wed, 2004-05-19 at 15:52 +0100, Tim Waugh wrote:
On Wed, May 19, 2004 at 03:42:48PM +0100, Tim Waugh wrote:
On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:
[...]
Is there a reason why the trigger is done that way round -- in the _cups_ specfile rather than the samba one? Or why we can't ship the extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts it directly into /usr/lib/cups/backend/ instead of making the symlink in a trigger script? Or any of the other possibilities?
That certainly sounds like the best thing to do for new packages. It would be best to keep the knowledge of that backend in the package that provides it.
I wasn't very clear here: I meant that any of these alternatives are better than putting it in cups.spec. :-)
Having a separate subpackage (which requires cups) sounds like the best approach.
OK, that's what I've done. A new set of bluez packages is in my yum repo at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/ (That's for FC2/ppc; i386 users can rebuild if they want).