From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 Description of problem: There are a bunch of *-devel requires in the php-4.1.2-7.3.3.i386.rpm specfile which probably don't need to be there (and get in the way of installing it). Version-Release number of selected component (if applicable): php-4.1.2-7.3.3 How reproducible: Always Steps to Reproduce: 1. Try to install php-4.1.2-7.3.3.i386.rpm on a system which isn't a development box. -or- 2. Look at the spec file. :-) Actual Results: $ rpm -qp --requires php-4.1.2-7.3.3.i386.rpm | grep devel bzip2-devel >= 1.0 curl-devel >= 7.9.5 db3-devel expat-devel freetype-devel >= 2.0.0 gd-devel gdbm-devel gmp-devel imap-devel >= 2000-9 krb5-devel libjpeg-devel libpng-devel libstdc++-devel libxml2-devel >= 2.4 mm-devel mysql-devel ncurses-devel openssl-devel pam-devel postgresql-devel pspell-devel ucd-snmp-devel unixODBC-devel zlib-devel Expected Results: Less (or no) *-devel requires. Additional info: Severity 'security', because this makes it difficult to apply the updates for RHSA-2002:102-26.
The errata are based on the premise that you have a fully installed system. While that might be a rather... 'arogant' position to take, it's the only maintainable way that we can provide errata. Developers cannot be expected to continually reload their development boxes to do progressive installation testing. ie minimal, workstation, server, full and custom. The overhead would be astronomical. It's for this reason that Red Hat created the RHN network service. (see below) You can force the issue with rpm -Fvh php*rpm --nodeps Please also note that you should carefully edit the /etc/php.ini file to suit your setup. Don't just assume that they are correct for your system. Phil =--= [root@zenIIIa root]# up2date php php-devel php-imap php-ldap php-mysql php-odbc php-pgsql php-snmp Retrieving list of all available packages... ######################################## Removing installed packages from list of updates... ######################################## Removing packages with files not specified from list... Removing packages marked to skip from list... ######################################## Getting headers for available packages... ######################################## Removing packages with files marked to skip from list... ######################################## Testing package set / solving RPM inter-dependencies... ######################################## The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- bzip2-devel 1.0.2 2 curl-devel 7.9.5 2 expat-devel 1.95.2 2 freetype-devel 2.0.9 2 gd-devel 1.8.4 4 gdbm-devel 1.8.0 14 gmp-devel 4.0.1 3 imap 2001a 10 imap-devel 2001a 10 krb5-devel 1.2.4 2 libjpeg-devel 6b 19 libpng-devel 1.0.14 0.7x.3 libstdc++-devel 2.96 112 libxml2-devel 2.4.19 4 mm-devel 1.1.3 8 ncurses-devel 5.2 26 pspell-devel 0.12.2 8 ucd-snmp-devel 4.2.5 7.73.0 ucd-snmp-utils 4.2.5 7.73.0 unixODBC-devel 2.2.0 5 zlib-devel 1.1.3 25.7 Retrieving selected packages... php-4.1.2-7.3.3.i386.rpm: ########################## Done. php-devel-4.1.2-7.3.3.i386. ########################## Done. php-imap-4.1.2-7.3.3.i386.r ########################## Done. php-ldap-4.1.2-7.3.3.i386.r ########################## Done. php-mysql-4.1.2-7.3.3.i386. ########################## Done. php-odbc-4.1.2-7.3.3.i386.r ########################## Done. php-pgsql-4.1.2-7.3.3.i386. ########################## Done. php-snmp-4.1.2-7.3.3.i386.r ########################## Done. bzip2-devel-1.0.2-2.i386.rp ########################## Done. curl-devel-7.9.5-2.i386.rpm ########################## Done. expat-devel-1.95.2-2.i386.r ########################## Done. freetype-devel-2.0.9-2.i386 ########################## Done. gd-devel-1.8.4-4.i386.rpm: ########################## Done. gdbm-devel-1.8.0-14.i386.rp ########################## Done. gmp-devel-4.0.1-3.i386.rpm: ########################## Done. imap-2001a-10.i386.rpm: ########################## Done. imap-devel-2001a-10.i386.rp ########################## Done. krb5-devel-1.2.4-2.i386.rpm ########################## Done. libjpeg-devel-6b-19.i386.rp ########################## Done. libpng-devel-1.0.14-0.7x.3. ########################## Done. debug1: channel request 0: window-change libstdc++-devel-2.96-112.i3 ########################## Done. libxml2-devel-2.4.19-4.i386 ########################## Done. mm-devel-1.1.3-8.i386.rpm: ########################## Done. ncurses-devel-5.2-26.i386.r ########################## Done. pspell-devel-0.12.2-8.i386. ########################## Done. ucd-snmp-devel-4.2.5-7.73.0 ########################## Done. ucd-snmp-utils-4.2.5-7.73.0 ########################## Done. unixODBC-devel-2.2.0-5.i386 ########################## Done. zlib-devel-1.1.3-25.7.i386. ########################## Done. Preparing... ########################################### [100%] 1:bzip2-devel ########################################### [ 3%] 2:curl-devel ########################################### [ 6%] 3:expat-devel ########################################### [ 10%] 4:freetype-devel ########################################### [ 13%] 5:gd-devel ########################################### [ 17%] 6:gdbm-devel ########################################### [ 20%] 7:gmp-devel ########################################### [ 24%] 8:imap ########################################### [ 27%] 9:imap-devel ########################################### [ 31%] 10:krb5-devel ########################################### [ 34%] 11:libjpeg-devel ########################################### [ 37%] 12:libstdc++-devel ########################################### [ 41%] 13:libxml2-devel ########################################### [ 44%] 14:mm-devel ########################################### [ 48%] 15:ncurses-devel ########################################### [ 51%] 16:pspell-devel ########################################### [ 55%] 17:ucd-snmp-devel ########################################### [ 58%] 18:ucd-snmp-utils ########################################### [ 62%] 19:unixODBC-devel ########################################### [ 65%] 20:zlib-devel ########################################### [ 68%] 21:libpng-devel ########################################### [ 72%] 22:php warning: /etc/php.ini created as /etc/php.ini.rpmnew ########################################### [ 75%] 23:php-devel ########################################### [ 79%] 24:php-imap ########################################### [ 82%] 25:php-ldap ########################################### [ 86%] 26:php-mysql ########################################### [ 89%] 27:php-odbc ########################################### [ 93%] 28:php-pgsql ########################################### [ 96%] 29:php-snmp ########################################### [100%]
I beg your pardon but this doesnt make any sense. The package dependancies are plain broken, admit that and move forward by releasing another set of php updates.
Those dependencies are incorrect; the php binary RPM doesn't actually *require* all of that.
Looking at the spec, I think that some bits only required by php-foo have found their way into the Requires: for the parent php package -- or perhaps they only need to be BuildRequires? I've rebuilt the package without the -devel requires but leaving them as BuildRequires and in the subpackages, and that seems to make things work as expected. Note that the current Requires: list forces you to install: both mysql and postgres, even if you haven't installed php-mysql and php-pgsql; ldap, even if you haven't installed php-ldap; unixODBC, even if you haven't installed php-odbc; snmp, even if you haven't installed php-snmp; and imap, even if you haven't installed php-imap. I hope this clarifies the bug report.
This is preventing us from installing this on several production machines as well, because we do not have installed and do not intend to install postresql, imap, or unixODBC on these machines because we don't need them. We do not have php-pgsql, php-imap, or php-odbc installed, and are not trying to update those. We shouldn't be forced to install all these services we don't need in order to update something that doesn't even use them.
imap > 2000-9 requirement on main php package is garbage as well. Does php-imap require imap on same server either?
This is being worked on. For now just apply with --nodeps or wait for the newer errata. The appropiate people in QA have been chastised.
Actually, Redhat here are right. Don't chastize your QA people. almost. PHP does actually require all these packages listed. We need them to be able to use the libraries they provide. (hence, the -devel packages). This is also the reason we no longer provide a rpm; PHP like so many other things is different from install to install. We don't even have a default install ourselves, just a few extensions that get compiled in by default (and they are only standalone extensions, or ones with bundled libraries -- and we're even having some issues with those.) My recommendation as a PHP developer to system admins is to not use a rpm. I know that's an inconvenience, rpms make life easier, so, My recommendation to redhat is to prepare a few PHP packages with either "all", "none" or "popular" extensions. What would make even more sense would be to install extensions based on whether the other deps exist, and be a bit more automatic about it than currently exists. Phil: feel free to email me -- i will do what I can to assist you. Thanks, James cox
> PHP does actually require all these packages listed. We need them to be able > to use the libraries they provide. (hence, the -devel packages). Confusion present. The "php" rpm should not require postgres; that's required by the "php-pgsql" rpm. Ditto for the others I listed. Similarly, the "-devel" rpms don't contain shared libraries; they contain header files and static libraries used during compilation. This bug says "Please make the PHP errata rpms work like all of the other PHP rpms Red Hat has released."
Created attachment 71704 [details] Ammended php spec file that does away with a load of the dependancies that really wern't needed
James: your comment shows some lack of understanding about how things like php are distributed in a package based distribution like RedHat. Please have a look the the stock php rpms in the rh 7.3 installation. php-4.1.2-7.i386.rpm php-dbg-4.1.2-7.i386.rpm php-devel-4.1.2-7.i386.rpm php-imap-4.1.2-7.i386.rpm php-ldap-4.1.2-7.i386.rpm php-manual-4.1.2-7.i386.rpm php-mysql-4.1.2-7.i386.rpm php-odbc-4.1.2-7.i386.rpm php-pgsql-4.1.2-7.i386.rpm php-snmp-4.1.2-7.i386.rpm of these only the extension specific rpms like php-imap, php-ldap, php-mysql etc. depend on a additional corresponding module. (and not its -devel part) php-4.1.2-7.i386.rpm is the core php module as a DSO and it doesnt depend on any of the libraries needed by the extensions
I'm in shock. An upstream person that doesn't want to rip my throat out. You are correct. It's extremely difficult to try and steer a straight path from php release to php release and keep everyone happy. I've tried quite hard to make work as expected given that I've to balance everyone's demands of 'we want extension XYZ' and 'Security blunder of the week is in extension XYZ'. Basically no one is satisfied. When you compound that across the various RHAT releases (7.0, 7.1, 7.2, 7.3 and AS2.1) it becomes an insane juggling act as all have differing levels of extension library levels and API's available. I am human, damnit. I make mistakes. Other people in the chain also make mistakes. ANYWAY, all this aside, I am in the process of making a 4.1.2-7.3.4 errata and then carry backwards through the chain to 4.1.2-7.0.4 For those that can't wait, if you downloaded the source rpm (and have the disk space)... rpm -ivh php-4.1.2-7.3.3.src.rpm cd /usr/src/redhat/SPECS <copy the attachment in the next message in as php-4.1.2-7.3.4.spec> rpmbuild -ba php-4.1.2-7.3.4.spec That should build you a set of php-4.1.2-7.3.4* rpms that you can then install without the dependancy issues. Phil =--=
Created attachment 71705 [details] Ammended php spec file that does away with a load of the dependancies that really wern't needed
oops, yea, i just noticed that when we say, binary, built, that doesn't mean the same as a dependency package, but instead, static. :)
> php-4.1.2-7.i386.rpm is the core php module as a DSO and it doesnt depend on > any of the libraries needed by the extensions what concerns me is that you can only specify one shared object for apache to parse php. Of course, you can add in the other shared objects via php.ini. However, this must suck; shared objects loading shared objects loading libraries. eeew. I am sure there might be a better way of doing this...
Phil: all said aside I think all of us depending on your packages are thankful for your prompt (second) response. No one is immune from making mistakes. Thanks.
And for all those that noticed,.. it's 'Requires: bzip2' not bzip in the attached spec file... Phil =--=
*** Bug 72063 has been marked as a duplicate of this bug. ***
QA should always test the "trimmed down, all unnecesary packages removed" scenario. Do not assume all your customers happily select "Server install". ;-) That being said, the upgrade is welcome, 4.1.2 is a good thing to have, 4.0 was already kind of old. But please pay more attention to the testing. :-) Regards,
We've modified our QA procedures to explicitly check, for errata packages, what dependancies have changed since the last revision we shipped. That should help catch this problem in the future. As Phil states we've reopened the errata and will be building, QA'ing and pushing out replacement packages shortly.
BuildRequires should list the -devel packages, not the libraries. The -devel packages already have the dependecy fot the libraries (at least they should). apache-devel was missing, btw. The utils for the install scripts should be PreReq? (i guess here, as RPM docs are always outdated :(
Created attachment 71884 [details] fixes for problems described above, please have a look
Yes, you are correct. perl does need to be a prereq, but fileutils and bzip2 are probably buildprereqs, as I don't see them used in the %post/%preun scripts. Sorry phil, but its _another_ respin.
*** Bug 72133 has been marked as a duplicate of this bug. ***
(pzb) aye, the above spec file replacement was a quick 'get out of jail free' I've a better one that we're QAing atm Bare with us. (rblath) You're correct, the BuildRequires should all be -devel packages. I made the assumption that just because the library was available in, say for example, pam, that things would be ok, but neglected to account for the likes of header files that would be necessary for the compiler to know about. Live and learn. Least you get to debate what should be in there. (imajes) What where you thinking about? Creating a few php.ini files that should be bundled in like php.ini.none, php.ini.popular, php.ini.kitchensink Oh, yes, I'm not the tester, but the failures in the QA mechanism have been highlighted and additional test proceedures have been applied. Phil (the unworthy) =--=
Ok,. lets have a shot with this proposed spec file ... attached below Phil =--=
Created attachment 72004 [details] Proposed new errata spec file.
Does it _really_ need all of those explicit deps? Are you sure some of the deps aren't sub-deps of the other build deps? Just a thought... Don't want to see our good man Phil get barbequeued by hundreds of angry php users. ;o) You might want to add 2 other deps too: Requires: gnome-core, kdebase ;o)
I've installed all the packages related to the Php4 update, and I end up with having Ldap connection problem with the error message below, is that a bug when make this update? I can actually run everything in the last version without changing any configuration. Fatal error: Call to undefined function: ldap_connect() in... Is anyone having the same problem?
You almost never need Requires for any library package, all such dependencies are generated automatic (and are pointing to exact library files). And those file dependencies are the best thing rpm has. ronny
There are a few Requires for the subpackages because RPM doesn't pick them up even though the libraries the shared objects rely on are available through the BuildRequires. ie without them, a minimally installed box will fail as follows [root@test121 i386]# rpm -ivh php-*7.3.4* error: failed dependencies: libmysqlclient.so.10 is needed by php-mysql-4.1.2-7.3.4 libodbc.so.1 is needed by php-odbc-4.1.2-7.3.4 libpq.so.2 is needed by php-pgsql-4.1.2-7.3.4 libsnmp.so.0 is needed by php-snmp-4.1.2-7.3.4
No, the dependencies on the library files are absolutly sufficient. here's an example to make it clear --- ronny@vlugnet:~$ rpm -q --provides mysql libmysqlclient.so.10 mysql = 3.23.41-1 --- this stuff is handled automatically, you don't need the Requires field. ronny
It does not hurt to have those libraries (if you assume they're pretty static, ie. package names won't change) spelled out. It's nicer for the user. rpm -q --provides only helps if you have the required package installed.. if you don't, you need to first find out where to get it. That's what "spelled-out" library lines are good for, less hassle.
To dcmwai.my: Perhaps you're experiencing the same problem as i did with MySQL. The php.ini that comes with the buggy PHP updates does not contain refferences to the actual .so modules that implement mysql, ldap, etc. You have to edit /etc/php.ini and add "extension=ldap.so" somewhere. I'm not sure if ldap.so is the name; to me, mysql.so did the trick. I actually opened ticket #72074 on this problem. Read it here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72074
Every update tool is handling file dependencies (up2date or apt). Also rpmfind does in some way. There is really no need for requiring packagenames (which can change and actually do at some times). And it would make writing spec files more error-prone. Changing package names (splitting of packages etc) would practically be impossible. RH is switching almost every package to this scheme, and that's a Good Thing(TM). ronny
ronny, in qa testing, the eutopian ideal doesn't work, we've had to make it require a few packages for those that have minimal installs on their boxes. Phil =--=
Would it be possible to create a /etc/php.ini.d like the profile.d etc dirs - if there was a good way of getting php to read through a set of ini's you wouldn't have to sort with re-editing an ini file. Would this be possible/reasonable for the upstream developer to implement? It would make this aspect of packaging easier.
To skvidal.edu: That is a clever idea, but requires PHP to understand #include directives in the .ini file. Is that possible?
Couldn't something be done similar to how mozilla handles loading extensions, like mozilla-psm, mozilla-mail, etc.? I think there's a PERL script that is executed for the %post and %postun scripts. This way, a similar script could be packaged with the base php RPM, and then additional RPMs such as php-imap, php-mysql, etc. could call this PERL script after they are installed or removed. The PERL script could then enable whatever extensions are currently loaded.
> ronny, in qa testing, the eutopian ideal doesn't work, we've had to make it > require a few packages for those that have minimal installs on their boxes. The packages are also required if they are not explictly listed (through the library files). Sorry, cannot follow here. Isn't up2date in minimal install? (If yes, I would consider THIS a bug.) But nevertheless you can find out the package name without big problems, often by simply guessing. Adding the explicit Requires is IMHO plain wrong, because only the libraries are really needed and these can live in every package they like. These Requires lines are in the best case redundancy. ronny
*** Bug 72372 has been marked as a duplicate of this bug. ***
This is still an issue on Red Hat 7.2. My cow-orkers verify this is fixed on 7.3.
so I noticed 7.X.4 came out on friday - are these the right pkgs? The depends looks better.
What's interesting to me is that as of one hour ago, up2date for 7.3 still installed php-4.1.2-7.3.3. Any hope to see 7.3.4 for the up2date people?
*** Bug 72467 has been marked as a duplicate of this bug. ***
*** Bug 72469 has been marked as a duplicate of this bug. ***
We created those new packages and pushed them to ftp but before pushing to the Red Hat Network a new PHP security advisory came out. We're just analysing the new issues before deciding on pushing those fixed packages to RHN or quickly creating replacements based on the new advisory and pushing those instead.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2002-102.html