Bug 538101 - [patch] Add "postscriptdriver" tags to packages
[patch] Add "postscriptdriver" tags to packages
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: python-cups (Show other bugs)
16
All Linux
low Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 456906 F13Target
  Show dependency treegraph
 
Reported: 2009-11-17 11:20 EST by Tim Waugh
Modified: 2011-10-06 03:19 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-05 16:06:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Tim Waugh 2009-11-17 11:20:46 EST
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 11:01:16 EST
Created attachment 373159 [details]
postscriptdriver.prov

Here's the 'postscriptdriver.prov' provides script needed by the patch.
Comment 2 Tim Waugh 2010-01-07 07:16:17 EST
*ping*

This is needed by a feature targeted for Fedora 13.
Comment 3 devzero2000 2010-01-07 09:20:10 EST
(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 11:57:43 EST
Would be great to get this in before any mass rebuilds start...
Comment 5 Panu Matilainen 2010-01-30 06:04:07 EST
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 07:56:52 EST
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 07:15:23 EST
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 02:59:11 EST
+	    /* 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 05:24:17 EST
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 06:24:06 EST
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 06:43:24 EST
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 07:37:12 EST
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 08:29:03 EST
Ok, the latest version added to rpm-4.8.0-6.fc13 in rawhide now. Thanks!
Comment 14 Tim Waugh 2010-02-05 05:45:09 EST
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 06:09:00 EST
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 06:24:27 EST
Also tested with hplip.
Comment 17 Panu Matilainen 2010-02-05 08:09:42 EST
Ok, built into rpm-4.8.0-7.fc13 now.
Comment 18 David Woodhouse 2011-10-05 10:29:05 EDT
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 11:19:02 EDT
Changing component to python-cups, which is where that file lives now.
Comment 20 David Woodhouse 2011-10-05 16:06:02 EDT
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 03:19:22 EDT
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.