[Bug 226295] Merge Review: php-pear

bugzilla at redhat.com bugzilla at redhat.com
Tue Feb 6 17:09:41 UTC 2007


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Merge Review: php-pear
Alias: php-pear

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226295





------- Additional Comments From chris.stone at gmail.com  2007-02-06 12:09 EST -------
(In reply to comment #12)
> - the source code files distributed in PEAR carry a copyright notice with the v3
> license.  Those copyright notices alone define how the source code is licensed,
> and the License tag on the package should reflect that and only that.

Indeed the source files specify the 3.0 license and this carries more weight
than the license linked to on the web site.  Thank you for clarifying this.

> 
> - the .phar archive is the only way found to bootstrap PEAR

Indeed, however the point is we do not need to bootstrap PEAR.


> 
> - it is desirable to have PEAR build from a separate source RPM; it has an
> independent upstream (and hence release cycle) to PHP, and we can ship updates
> to this small self-contained part without revving the entire PHP package (which
> is large, fragile, and needs lots of QA for every update).  There is
> insufficient motivation here to change that.

Okay, now you are contradicting yourself.  There are several points I should
make in reards to this statement:

1) It is desirable to have the PEAR class separate from php, (NOT the pear
installer).  Therefore we should have a php-pear-PEAR rpm that contains ONLY the
PEAR class.  The PEAR *class* is what is updated frequently, and the pear
installer does *NOT* get updated frequently.

2) It makes perfect sense to include the pear INSTALLER with the php class. 
This has several very important benefits.  First it allows us to package the
classes individually using the standard default template spec files.  It allows
us to use the standard .tgz files for the classes.  This allows us better
auditing and allows us better freedom for updates to the classes.  And all the
classes will be packaged in seperate SRPMS for better consistency and just makes
sense.

3) There is HUGE motivation to change this.  I do not understand why you do not
see it.

4) The bootstrapping method uses a source file which changes at every single
release, there is no way for someone to download an old version of the bootstrap
code.

5) The bootstrap code bunches several pear classes together in a large lump sum
which actually makes it more difficult to make incremental updates which
contradicts the reasoning you mention above.

6) PEAR 1.5.0 adds a gtk and web interface, by using the bootstrapping method
you again bring in all these extra packages (some of which are already packaged
seperately) into a single lump sum.  This even makes it more desirable to NOT
use the bootstrapping method and to simply add the installer in the php package.

7) with PEAR 1.5.0 there are already sepearate packages classes which PEAR now
depends on therefore making the bootstrapping method conflict and clash with
existing packages.

8) The bottom line is that this *has* to be done.  We can no longer use the
bootstrap method because it is conflicting with too many existing packages and
it is simply causes a big mess and many problems.  It has to be done this way. 
If you need help I will be glad to help you.


> 
> - whatever package gets reviewed is subject to change as new upstream releases
> come out.  1.4.11 or 1.5.0 or 1.6.0.  1.4.11 is what's in Fedora at the moment
> and what's up for review.

Sir, I am getting sick and tired of explaining this to you and you are trying my
patience!

Pear 1.5.0 is going to bring on many signifacnt changes, it adds php-gtk, and a
web installer among other things.  This means it is even more important to break
these packages up into sepearate packages and to include the pear installer in
the php package like I suggested.  These changes are significant enough for me
to demand that they be done before the formal review.

We are going to be working together with this and major changes to how php and
php-pear are packaged are going to have to be made.  I am not here to make your
life difficult, I am here to try and assist you on the best way to package this.
 I hope that you understand the bootstrap method is just simply no longer going
to work, especially now with pear 1.5.0.


> - the License tag, presence or lack of %build, $RPM_SOURCE_DIR vs %{SOURCEn} -
> changing these is a bikeshed painting exercise unless and until specified by a
> Fedora packaging guideline.

Mr Orton, I have already brought this up with fedora packaging members and
several the suggestions I have made come straight from the packaging committee!
 If you want to bring this up to them again personally, I can do that.

So instead of spending 10 seconds making a simple benign change, you want to be
stubborn and escalate this to the packaging committee and waste their time with
this nonsense?  We can do that if you want, but I strongly urge you to put your
ego aside and just make the simple benign trivial changes.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the Fedora-package-review mailing list