Edward Dekkers <mailto:[EMAIL PROTECTED]> wrote on Wednesday, 15 January 2003 10:54:
>> For local RPM collections, RH8 has the Red Hat package manager. It's >> still a bit limited, but I believe they are working to make it >> better and more flexible. We'll see. But this is not the issue >> that is preventing RHL from taking over the world, and it's not so >> easy to fix that someone else has already done it. > > Just a quick note about this whole dependency thing. Firstly, yes, I > DO think it's a good thing when you need newer version of libs for > example. The thing that's always bothered me (AND the OP I might > add). Is that program XYZ requires a library OLDER than the one you > have installed. Three words: > > This is crap. Yes and no. See below... > THAT'S where I think the major problem lies. Libraries provide > functions. They should be added to, modified to make them faster, but > never, ever, change for example the number or type of parameters to a > function call. I do not know if that is what is happening or not, but > if so this is where the problems lies. It breaks > backwards-compatability. In an ideal world that would be the case, but the Linux world is basically a continually evolving/developing stream, which sometimes stretches backward-compatibility beyond breaking point. In the M$ domain they try hard but eventually they just create a new product for punters to hand over more money to get. If your apps aren't compatible with the new version (not a completely unknown occurrence) you just insert a note "see your vendor for a new version". (or the exact equivalent of this lib version issue - get an older dll revision and place it in the same directory as the application executable.) I feel Linux app and library developers do take a lot of care to maintain compatibility, but take GTK as a case in point. The changes involved in version 2 were necessarily large, to achieve the required result. I don't know what actual discussions took place around the new API but I am sure there was some trade-off between features/efficiency and compatibility. And backwards-compatibility lost, presumably for very good reasons. Although they went to some trouble to ensure coding changes in applications were at least minimised. So, you get two version of libraries that are not compatible. One option is to say that major revision number changes involve loss of backward compatibility. The other is to say we'll just give the product a new name. So long as everyone works to the same rules and people understand what they are, then there is little difference. That's not quite true - in the libc5 to libc6 changeover, insisting that libc6 be called something new and not a new version of libc would have been too traumatic. In the end I don't think the ideal is achievable. So this leads to... Is there a better way? I'm sure there are many, but I'm not prepared to implement any, so I'll shut up now. Cameron. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
