[Fedora-packaging] mass-filed --excludedocs bugs

Panu Matilainen pmatilai at laiskiainen.org
Mon Aug 10 12:13:03 UTC 2009


On Thu, 6 Aug 2009, Tom Lane wrote:

> "Tom \"spot\" Callaway" <tcallawa at redhat.com> writes:
>> On 08/06/2009 10:09 AM, Rex Dieter wrote:
>>> It would seem an enterprising contributor has taken it upon themselves
>>> to mass-file bugs wrt installing packages using --excludedocs.
>
> Yeah, I got some of those too.
>
>>> Should the guideline be changed to suppress the erroneous output, or
>>> checks added (as suggested in the aforementioned bug), like
>>> [ -f %{_infodir}/pinentry.info ] && ...
>
>> Well, if there is output that we wouldn't want suppressed, we could do
>> the file check, but I'm wondering how much of a slow down it would be to
>> check for that file several hundred times in a large transaction.
>
> I definitely want to see the guidelines changed in one way or the other;
> we shouldn't have individual packagers making their own choices about it.
>
> Personally I think that 2>/dev/null is just too dangerous, and some sort
> of scripted check is the way to go.  Is there any other way for a
> specfile to know whether it's been installed with excludedocs?
> I'm imagining
> 	%if !excludedocs
> 		.. run install-info ..
> 	%endif
> which hopefully would be cheap enough to answer spot's concern.

No, excludedocs and other similar mechanisms aren't exported to 
scriptlets.

There are number of issues with the above %if .. %endif idea:
- macros in scriptlets get expanded at build-, not install time
- %if .. %endif style conditionals only exists in the spec parser
- excludedocs & other similar are only relevant during install-, not at
   build-time

Sure it'd be possible to export the information through environment 
variables, so the above snippet would become something like

if [ -z "$RPM_EXCLUDE_DOCS" ]; then
    ... run install-info
fi

...but that wouldn't do anything to help things like %_install_langs, 
%_netsharedpath, --excludepath etc. And really, the scriptlets are 
cluttered enough already without having all of them try to work with 
each and every obscure rpm switch and "feature."

There's a big pile of related issues which want essentially event-driven 
(think of "/usr/share/foo got removed/installed/modified") actions.

 	- Panu -




More information about the Fedora-packaging mailing list