On Sat, 2002-12-14 at 02:01, David van Hoose wrote: > Here are the changelog addresses for KDE 3.0.4 and KDE 3.0.5. Read them > and tell me what could possibly "break" any 3.0.3 program on your > system? I want a list. Take as much time as you need. > > http://www.kde.org/announcements/changelogs/changelog3_0_3to3_0_4.html > http://www.kde.org/announcements/changelogs/changelog3_0_4to3_0_5.html > > -David
I assume their are library changes. Whether or not the libraries are 100% binary compatible with the old I do not know. But if they are not, then it is possible for locally compiled software or third party software that are linked against the older libs to break. Yes - it happens. Just last week I compiled a new rpm for fontconfig from the new version. It installed just fine and everything - but both gnome and kde broke - as in applications that needed xft2 would either start and exit or start but not render the fonts. These same applications worked perfectly in WindowMaker though (oddly enough). So that is an example where a package much smaller than KDE breaks stuff when a version is upgraded. I suspect I could rebuild gnome and kde and all would be good - but that is what RH is trying to avoid its users and 3rd party vendors from having to do. Red Hat's philosophy is the correct one. Users who really want KDE 3.0.5 can download it from http://www.kde.org/ It is free as in beer and free as in speech. Red Hat, on the other hand, needs to support an environment where some applications will be compiled on the machine (and as such up2date has no control over them) and some applications installed by third party (again - which up2date has no control over). Perhaps there is not a technical reason as far as library compatibility - but all it takes is me have one rpm from one vendor that has the following in its spec file: Requires: kdelibs = 3.0.3 and guess what - wether or not that application would work w/o recompiling with KDE 3.0.5 up2date will not be able to install the KDE update because it would break the dependency issues of another RPM. If its a popular 3rd party rpm - that would cause quite a bit of people complaining that up2date isn't working and they can't apply the security patch. Red Hat is doing it the right and proper way. > > Michael A. Peters wrote: > > >As a future hardware OEM that will be pre-installing Linux I can say > >that this feature of Red Hat is EXACTLY why I really think we will OEM > >Red Hat with our systems. > > > >Applying the patches to the version of the package that shipped with > >their distro is the best and proper way to do it. It really is. > > > >Why? > > > >You may have stuff in /usr/local that is compiled against the libraries > >in kde-3.0.3 > > > >If Red Hat were to have offered an update to kde-3.0.5 w/ RH8 then guess > >what - some of the software that you have in /usr/local (or ~/) that is > >linked against kde-3.0.3 would break. > > > >I sure as hell don't want to have to choose between "applying a security > >fix and breaking software" or "don't apply security fix" > > > >Red Hat is doing the prudent thing by back porting security fixes into > >the version of the software they shipped whenever possible. > > > >It ultimately provides the best integration between applications > >provided by the OS vendor (Red Hat), applications provided by third > >party vendors designed to work with Red Hat, and applications compiled > >on your machine. > > > >So please - before anyone else britches about Red Hat not providing > >updated versions but rather backports fixes - please educate yourself - > >as that is the PROPER way to do things. > > > >DISCLAIMER > >This rant is not specifically aimed at David van Hoose. > >I just quote his mesage. > > > >On Fri, 2002-12-13 at 09:54, David van Hoose wrote: > > > > > >>You are not alone. > >>I sent RedHat a message addressing the issue about how they are > >>releasing older packages with their set of security fixes rather than > >>helping patch the program's CVS so that ALL of the newer versions of the > >>program will be patched. I find that RedHat is in essence pulling a > >>Micro$oft in that they will not share. > >>I find it kind of iritating that RH just released an update for KDE > >>3.0.3 instead of releasing 3.0.5 which had the same fixes. Some programs > >>should be tested, but others are already being tested and fixed on a > >>daily basis. > >>I think that if we all complain about this, that they might modify their > >>policy on security fixes. > >> > >> > >> > > > > > > > > -- Michael A. Peters <[EMAIL PROTECTED]> -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
