Yes there are library changes, but no they cannot break your program unless your program relies on a bug or a security hole. It is safe to upgrade (in most every case) programs with only the 3rd number of the release or the revision number different. The differences are strictly fixes to what is already there. And projects that do this should be checked for security holes, but should be provided to maintain the official version scheme.
-David
PS. I have never had a problem with fontconfig breaking things. Send me information to my email address listed. I'm curious.
Michael A. Peters wrote:
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.I assume their are library changes.
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
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.
-- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
