Bug 538101

Created attachment 373159 [details]
postscriptdriver.prov

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

*ping*

This is needed by a feature targeted for Fedora 13.

(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

Would be great to get this in before any mass rebuilds start...

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).

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...

Created attachment 388516 [details]
rpm-postscriptdriver.patch

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

+	    /* 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)?

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.

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?

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.

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.

Ok, the latest version added to rpm-4.8.0-6.fc13 in rawhide now. Thanks!

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.

Created attachment 389044 [details]
rpm-postscriptdriver-fixes.patch

Here is an incremental patch to fix these issues.

Tested with gutenprint, foomatic, cups.

Also tested with hplip.

Ok, built into rpm-4.8.0-7.fc13 now.

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.

Changing component to python-cups, which is where that file lives now.

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.

Yes, rpm's file classification looks inside compressed files, largely for reasons like this one (fonts being another common case).