[Fedora-packaging] PHP guidelines

Christopher Stone chris.stone at gmail.com
Wed Jul 26 19:04:54 UTC 2006


On 7/25/06, Ville Skyttä <ville.skytta at iki.fi> 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.




More information about the Fedora-packaging mailing list