On Wed, 2004-12-08 at 12:48 -0500, Alan Cox wrote: > On Wed, Dec 08, 2004 at 12:39:22PM -0500, Sean Middleditch wrote: > > that have absolutely no negative impact on how Linux works now for any > > users while potentially improving things for other users. Better > > packaging isn't going to hurt anyone, but it will help. I haven't yet > > Im still a little confused the precise points you want to see improve. Can you > enumerate them as concise points ? The biggest thing Red Hat could do is simply provide a little cleaner packaging. There are libraries that Red Hat packages which are clearly capable of being parallel installed and otherwise working beautifully, but Red Hat's packages cause artificial incompatibilities. Take the libcurl examples from the other thread. The curl package has both the libcurl library and the curl utility. When curl was upgrade, it dropped libcurl.so.2 and added libcurl.so.3. There is only one package that, depending on version, provides two totally different interfaces. You can't even manually install both versions since both include the curl utiltiy and thus have true conflicts. I had a third part open source app (Xine) that depended on libcurl.so.2. Apps from Fedora requires libcurl.so.3. It took around a month for a new Xine compiled against libcurl.so.3 to appear. I had to uninstall and not use Xine for a month. However, there was no reason why this should have happened. Both libcurl and Xine were correctly functioning and well written in terms of library interfaces. The entire problem with artificially created by the RPM packages. If libcurl had been split from the curl package and given proper names like libcurl02 and libcurl03, this problem never would have occured. The upgrade would have installed libcurl03, any utilities/apps that needed libcurl.so.3 would be satisfied, and apps that still needed libcurl.so.2 wouldn't have any problems as the packages would be stick in this exclusive "one or the other" problem. It's just little stuff like that I want to see fixed. That's it, on Red Hat's part. In general, I'd like to see more responsibility on the part of certain library developers. Mike Hearn and Havoc Pennington have written some pieces on all the details of library management, I don't think I can really say it any better than they did. ~_^ > -- Sean Middleditch <elanthis@xxxxxxxxxxxxxxx> AwesomePlay Productions, Inc.
