* Peter Poeml wrote on Tue, Jul 02, 2002 at 21:38 +0200:
On Tue, Jul 02, 2002 at 07:39:10PM +0200, Oliver Bleutgen wrote:
contains links to mod_contrib.rpm, mod_perl.rpm and other modules for apache 1.3.19.
Strictly speaking those module updates should not have been necessary.
I though, RPM processes such dependencies automatically.
The module API has not changed since back 1.3.12 days. However, there are some other package interdependencies as well -- (if you ever typed ldd /usr/lib/apache/libphp4.so you know what I mean...)
php is linked only against /lib/lib*so :)
so if for example openldap has been updated meanwhile as well and the API used by php has actually changed, you might end up updating a rebuilt php package as well. I.e. a package like mod_php might have to rebuilt quite often. Now the problem is not, for us, to track down these build dependencies, but to cut them down by translating them into a set of packages that need rebuilding/updating (on your system!) or not.
I don't see the problem. When building upgrade packages, you use a compiler system which is excactly cd-inst plus patches. So the configure of mod_php cannot find a new openssl or ldap or whatever, since it's not installed. Well, bad example, mod_php fails anyway :). Of course especially in this example it could be possible that there is no "safe" mod_php version (well, actually I think that is true always :)) that builds with such old libs. I think the configure of mod_php is not smart with such issues. But in normal cases it should work. But of course you cannot build multiple things on the same filesystem, since it may happen that other things are installed (not part of the RPMs), theoretically. Theoretically an RPM build manager uses disk images that are restored after each package build.
It's very complex, unfortunately.
Yes, definitly it is.
Important: we assume that people have installed the previous security updates of apache. I hope that this is a fair assumption?
I think so. But I'm sure that not all servers are patched :). Isn't it possible to define the previous security update as RPM package dependency? If you say it depends on that, don't say it here, but tell it RPM :) Of course the FTP admin must make sure that the old version of the patch is still avialable, and I guess some people would be confused about it. Did we mentioned that it's very complex :)?
You had the modules from stock 7.0 installed (hope I got you right)? They should actually work with the current apache, with the exception of mod_ssl. Do you know which specific module failed?
I could imagine that not apache's dynalink failed, but the linkage of a module to a "system" lib due to changed entries or such. Well, but I though that there is a symbol table in the libs :) hum.
Sometimes, when we can't avoid to make version updates of packages (and apache 1.3.12->1.3.19 is such a candidate) it can't be guaranteed that the build procedure can actually be the same.
I would suggest to rebuild the source RPM, but with apache, this is very complex (did we mentioned that complexity already?).
Simply and boldly offering apache 1.3.26 updates for all distributions would be prone to break a lot of things because of changes like that. It would be hard to get it right again, so everything works still as expected, the configuration files are still valid, and so on.
Yes, and that's why software vendors/developer should provide backported patches. If this is not possible, problems will occure. I know that from php for instance, where you have to upgrade php on each bug, and often you have to upgrade a million libs, hack the configure m4 to make it compile...
As I understand it, we would need a special hint for users that have never installed one of the previous apache updates before.
Wrt the texts of the module update packages, they say "update package for apache 1.3.19". Which is what they ought to say.
I would like correct RPM dependencies (yes, I know it's difficult and... well... complex? :)) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.