On Thu, 6 Aug 2009, Tom Lane wrote:
"Tom \"spot\" Callaway" <tcallawa@xxxxxxxxxx> 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 -
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
