* Peter Münster wrote on Wed, Feb 21, 2001 at 19:56 +0100:
Why is this all so complicate? I think, that's why there are security announcements. Copy and paste the ftp://... line to your wget should do it.
That's theory. In practise you have at least to restart the service. You have to test the package, for that you need a non-productive testserver. That costs time. Remember i.e. the proftpd package. After upgrading passive FTP won't work. Bad, takes time. After upgrading the kernel freeswan won't work. Really bad, since it's difficult to recompile the kernel SRPM and freeswan.srpm. We had problems at bind updates (i.e. package splitting, at today's harddisk prices!). Sometimes configuration file syntax or semantics may change, adaption takes time. Those changes are not part of the annoucements but they should be I think. Sometimes the annouced packages came online later, the MD5 sums were wrong, the version numbers were wrong or misleading, old RPMs were announced as new ones or RPMs hab problems (especially for older SuSE versions) at installing (i.e. changes depencies). It's quite clear that such things happens. I will use the example of proftpd to explain it a litte. Proftpd had a securtiy problem. The package maintainer took the newest version and built an RPM. The version of the sources contained a little logical bug causing passive FTP to be not working. Such silly mistakes just happen, every programmer knows that. A patch was out (a time before the update came out). The pachager cannot read every mailling list, so it just may happen that buggy updates came out. (OK, I thing it's not a special thing to TEST passive FTP on a FTP server, but that's a different topic). The new RPM gets installed on a SuSE test host before publishing. If they don't install that system every time from scratch, many updated packages are installed on this test host. So the new RPMs may have new depencies (an updated lib or similar). So the package may work only on the test (or build-) host. If you install that package, you may have not updated such a package, and RPM may refuse to install, since you have an old lib (or whatever). Usually you don't even know what package you need to update to get this new version, and maybe it's not published, that may happen. All in all, you cannot expect a SuSE update to work or even that it's installable. So you need to test it for yourself, which is expensive and you cannot test is as well as SuSE could do, if they would try it, since you may have no people have enough time. A solution could be, that SuSEs test hosts get a plain installation back after testing (maybe from a disk image). But the build hosts cannot build useing insecure libs. Depencies are very complex, so it's not easily possible to make secure package without new depencies. SuSE should "diff" the depencies, announce the differences and what packages are required to solve the new depencies. You know what I'm talking about if you ever maintained RPMs for different versions in different installtions. If you do it on your own, you have a nice advance: mostly you will so all the same updates on all hosts, so you have all the same versions on every host, and you won't even notice new depencies, since they are solved on all hosts. Here we cannot rely that all admins install the same updates (especially if not security-relevant). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.