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@xxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review