Bug 538101 - [patch] Add "postscriptdriver" tags to packages
Summary: [patch] Add "postscriptdriver" tags to packages
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-cups
Version: 16
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 456906 F13Target
TreeView+ depends on / blocked
 
Reported: 2009-11-17 16:20 UTC by Tim Waugh
Modified: 2011-10-06 07:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-05 20:06:02 UTC
Type: ---


Attachments (Terms of Use)
rpm-postscriptdriver.patch (1.96 KB, patch)
2009-11-17 16:20 UTC, Tim Waugh
no flags Details | Diff
postscriptdriver.prov (7.47 KB, text/plain)
2009-11-23 16:01 UTC, Tim Waugh
no flags Details
Alternative approach to make it more rpmfc-style (2.50 KB, patch)
2010-01-30 12:56 UTC, Panu Matilainen
no flags Details | Diff
rpm-postscriptdriver.patch (13.20 KB, patch)
2010-02-03 12:15 UTC, Tim Waugh
no flags Details | Diff
rpm-postscriptdriver.patch (13.07 KB, patch)
2010-02-04 10:24 UTC, Tim Waugh
no flags Details | Diff
rpm-postscriptdriver.patch (11.67 KB, patch)
2010-02-04 12:37 UTC, Tim Waugh
no flags Details | Diff
rpm-postscriptdriver-fixes.patch (2.99 KB, patch)
2010-02-05 11:09 UTC, Tim Waugh
no flags Details | Diff

Description Tim Waugh 2009-11-17 16:20:46 UTC
Created attachment 369910 [details]
rpm-postscriptdriver.patch

Description of problem:
In order to be able to automatically install printer drivers in the same way as gstreamer codecs or fonts, printer driver packages need to have special tags identifying each printer model they can drive.

Patch attached.

See also:
  https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation

Comment 1 Tim Waugh 2009-11-23 16:01:16 UTC
Created attachment 373159 [details]
postscriptdriver.prov

Here's the 'postscriptdriver.prov' provides script needed by the patch.

Comment 2 Tim Waugh 2010-01-07 12:16:17 UTC
*ping*

This is needed by a feature targeted for Fedora 13.

Comment 3 devzero2000 2010-01-07 14:20:10 UTC
(In reply to comment #2)
> *ping*
> 
> This is needed by a feature targeted for Fedora 13.  

This one https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation
i think

Comment 4 Tim Waugh 2010-01-21 16:57:43 UTC
Would be great to get this in before any mass rebuilds start...

Comment 5 Panu Matilainen 2010-01-30 11:04:07 UTC
Apologies for slow response...

As you undoubtedly noticed, getting the internal dependency generator to support this is much like trying to force a square piece through a round hole. rpmfc is built solely on the idea that a files dependencies can be determined from the type of the file, which is completely at odds with what's needed here.
I wouldn't be able to upstream this with a straight face, which is why I'm not very comfortable of putting it to Fedora either. Not really your fault, as there is no good way to do all this with current rpmfc.

That said, some of this can be sanitized: PPD files can be fairly accurately recognized by libmagic, allowing at least them to be handled cleanly the "rpmfc way". Which leaves us with .drv files and the, hmm, virtual drivers that can be whatever executables. Drv files can't be recognized by libmagic so there's no way but to apply path hacks. Assuming PPD's get assigned a type of their own (either RPMFC_PPD or perhaps a more generic RPMFC_PSDRIVER or such), the least ugly way to handle .drv's would probably be mapping .drv files in /usr/share/cups/drv/ (note that wine uses .drv extension too so it needs to look at the path) to appear as PPDs in rpmfcClassify() so they get handled through the same mechanism as PPDs. Which would leave just the drivers in /usr/lib/cups/driver/ for which there's no way but to add a kludge similar to the gstream-provides (you might have noticed that's not upstream either, exactly for the same reason).

Comment 6 Panu Matilainen 2010-01-30 12:56:52 UTC
Created attachment 387727 [details]
Alternative approach to make it more rpmfc-style

Attached is a demonstration of a more rpmfc'ish way of accomplishing this. Untested but should give you an idea (can't test it now but I'll try to make time for this next week)

The RPMFC_FOO color bits are almost used up, a different method (text based tags or something) is going to be needed very soon...

Comment 7 Tim Waugh 2010-02-03 12:15:23 UTC
Created attachment 388516 [details]
rpm-postscriptdriver.patch

Thanks.  Here's a tested version of that patch, complete with a working postscriptdriver.prov script.

Comment 8 Panu Matilainen 2010-02-04 07:59:11 UTC
+	    /* XXX Gzipped PPD files should appear as PPD files */
+	    else if (rpmFileHasSuffix(s, ".ppd.gz"))
+		ftype = "PPD file";

This part shouldn't be necessary as the libmagic lookups are done with MAGIC_COMPRESS. Did you just pull it in from the earlier patch or was it actually still necessary to get provides from .ppd.gz extracted (which would suggest there's something else going on)?

Comment 9 Tim Waugh 2010-02-04 10:24:17 UTC
Created attachment 388761 [details]
rpm-postscriptdriver.patch

You are quite right, that part is not needed.  I've removed it and re-tested it, and this is the resulting patch.

Comment 10 Panu Matilainen 2010-02-04 11:24:06 UTC
Ok... one more question: I'm not getting any postscript driver provides for foomatic-db-ppds, which seems to be a major source for PPD files. Is that intentional?

Comment 11 Tim Waugh 2010-02-04 11:43:24 UTC
No, I'll look into it.

Not all PPDs will generate postscriptdriver tags, only those with *1284DeviceID attributes in them.  That said, plenty of the foomatic-db-ppds files do have that attribute in them.

Comment 12 Tim Waugh 2010-02-04 12:37:12 UTC
Created attachment 388772 [details]
rpm-postscriptdriver.patch

The problem was that the postscriptdriver.prov script was being too strict about whether to consider PPD files.  The foomatic PPD files are shipped outside the expected paths, but the package ships a symlink (in /usr/share/cups/model) so that they are found.

Fix: remove the pathname checking, and just try opening the files as PPD files.

New tested patch attached, tested with foomatic-db, foomatic, hplip.

Comment 13 Panu Matilainen 2010-02-04 13:29:03 UTC
Ok, the latest version added to rpm-4.8.0-6.fc13 in rawhide now. Thanks!

Comment 14 Tim Waugh 2010-02-05 10:45:09 UTC
Thank you!

I've found some bugs in the provides script.

Firstly, if a file might be a CUPS driver but executing it fails, the script stops early.

Secondly, the script should set LD_LIBRARY_PATH to allow the binary to run from within the build root if it consumes libraries from the same package.

Comment 15 Tim Waugh 2010-02-05 11:09:00 UTC
Created attachment 389044 [details]
rpm-postscriptdriver-fixes.patch

Here is an incremental patch to fix these issues.

Tested with gutenprint, foomatic, cups.

Comment 16 Tim Waugh 2010-02-05 11:24:27 UTC
Also tested with hplip.

Comment 17 Panu Matilainen 2010-02-05 13:09:42 UTC
Ok, built into rpm-4.8.0-7.fc13 now.

Comment 18 David Woodhouse 2011-10-05 14:29:05 UTC
The foo2zjs package in rpmfusion provides gzipped PPD files in
/usr/share/cups/model/

In F15 the postscriptdriver.prov script doesn't even get run on them, because they don't match the following:

%__psdriver_path	^(/usr/lib/cups/driver/.*|%{_datadir}/cups/drv/.*\.drv)$
%__psdriver_magic	^PPD file.*$

They aren't in those directories, and 'file' doesn't thing they're PPD files... because they're compressed.

By adding |.*\.ppd\.gz to the __psdriver_path definition, I was able to make the package get appropriate Provides.

Comment 19 Tim Waugh 2011-10-05 15:19:02 UTC
Changing component to python-cups, which is where that file lives now.

Comment 20 David Woodhouse 2011-10-05 20:06:02 UTC
Hm, that change doesn't seem to be necessary after all. If I BR python-cups in the package, it does seem to work OK.

Comment 21 Panu Matilainen 2011-10-06 07:19:22 UTC
Yes, rpm's file classification looks inside compressed files, largely for reasons like this one (fonts being another common case).


Note You need to log in before you can comment on or make changes to this bug.