On 7/25/06, Ville Skyttä <ville.skytta@xxxxxx> wrote:
On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote:
> Well Ville made a bunch of changes to the spec file template so that
> it doesn't have to use macros.
That's just a "food for thought" patch attached to Bugzilla (#198706)
for comments, not committed anywhere yet.
> It essentially complicates the default
> spec template. The reason for adding all of this additional
> complexity is to support deprecated distributions.
Such as FC5 as it stands now? Shrug.
FC5 should get the new php-pear that is in testing now. I think it is
good enough to be added to updates.
The initial suggested template hardcoded /usr/bin/pear scriptlet
dependencies, but actually used %{__pear} in them. This is apparently
done to work around the case where even "make srpm" would fail if
%{__pear} is not defined (which would very likely result in eg. the
current FE buildsys not being able to build those packages for *any*
distro version without changes, because %{__pear} was not conditionally
defined in the specfile). But the above workaround is broken
everywhere, including when %{__pear} is defined, and makes the whole
%{__pear} macro questionable.
Actually there was no reason at all why I used /usr/bin/pear other
than I did not test it under mock and was being "safe than sorry". If
%{__pear} works under mock, then I would add it back and remove the
/usr/bin/pear BR.
There are several ways to fix the problem consistently. As far as I can
tell, all of them include either conditionally defining %{__pear} in the
specfile and using it everywhere, or not using it at all and reverting
to %{_bindir}/pear or /usr/bin/pear instead and using that everywhere.
In addition to the above, it would be good to 1) buildrequire something
that defines rest of the used macros, or 2) conditionally define them in
the specfile, or 3) forget about the rest of the macros and use
something like the "food for thought" approach. Until the macros are in
FC5, 1) (or not adding the BR) is a blocker for inclusion of the
template in rpmdevtools or a blocker for the new release of rpmdevtools
for FC5. 2) and 3) don't block anything, and would have the additional
benefit of working with earlier distro versions.
The spec file template I submitted should not be added until the
macros are in the php-pear package which hopefully should happen soon.
The package.xml issue mentioned in #198706 comment 3 needs some
attention too, and the comment contains a suggested fix.
I'm not going to spend any more time working on this. Please just
provide patches you would like to see applied over the
spectemplate-php-pear.spec and newrpmspec in rpmdevtools CVS
("fedora-rpmdevtools" in the "fedora" (not extras) CVS root) to bug
198706 when you've figured out what it will be.
> Also Ville insists on their being a %build section for an unknown
> reason.
I did provide a reason, you seem to choose to ignore it.
Well you keep referencing a bug number with your argument and the
comments made in the bug you refer to seem to suggest my point of view
rather than yours. Basically the bug reporter simply did not know
what he was doing. So this bug that you refer to basically
invalidates your claim that there is a problem with not adding %build.
So you provide some reason, then invalidate this reason with a bug
number and therefore you provide an unknown or null or void or
canceled out reason. Kind of like when matter collides with
anti-matter...
Basically none of this matters because we need the new php-pear in
updates first. Then we can debate about the spec file changes that
need to be made.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
