Very interesting and informative information, Leigh. I did not realize how proprietary things were in the earlier times. The merging of the ODSL (Open Source Development Labs) and the FSG (Free Standards Group) into the Linux Foundation and the attempt to try and bring increased standardization, may help. I wish that Novell was a Debian based distribution though.
Then put in the mix the new Microsoft/Novell interoperability lab strategy. Considering the statements Bob Muglia made last summer about how tight they plan to build virtualization with Xen to "support Linux in a very native and high performance way," it could impact the end users in a very positive way. But I am not sure if this will be anything for the desktop, since it seems geared mostly for the server. 73, Rick, KV9U Leigh L Klotz, Jr. wrote: >This is just what package managers do. >There are two main package managers: Debainls deb format and Red Hat's >RPM. > >Debian historically did a better job on resolving dependencies at >installation time (as opppsed to just reporting them), but part of that >ability was due to Debian have a good repository infrastructure into >which packages are placed and with which the dependencies can be >satisfied. > >It isn't really true that Debian has one repository, but they do have >one structure, and the divisions in them are multi-year long releases, >the status (stable, testing, etc.), and the license status (essentially >fully GPL or not). I am not a Debian expert so I may be shakey in this >area. But the point is you install and make choices, and can satisfy >dependencies through an integrated system. > >In RPM (used by Red Hat/Fedora SuSE, Mandrake, and a few others), there >was no repository structure integrated into RPM, no "root" repository, >and no way even for multiple repositories to be integrated. Part of the >reason the fragmentation was that Red Hat monetized the updates so >making it work without their for-pay service wasn't in their interest. >So with zred Hat you bought or downloaded their release ISO images and >updated wholesale. When the pace of security fixes began to require >something better, RedHat introduced a for-pay update service, limited to >RedHat. It put the dependency calculation on their servers, just to >make sure you paid for it. > >SuSE was no better in their pre-Novell days. They had no downloadable >ISO images at all, and copyrighted their installer, so it was >effectively impossible to get SuSE without paying for it. They did >offer their individual RPM files for download, but mnoetized the >installer. After Novell acquired them, that block went away. But there >is still a separate set of RPMs for SuSE. > >A couple of other companies tried to get into the updater business, and >they made variant versions of systems such as Gnome (or, the main >version and everyone else was variant, dependong on whom you ask). >Unfortunately, once you hopped on that train, you could never get off as >there were version conflicts deep down, and the whole thing faltered. > >Aound the time Fedora split off, the Yum system came about (it grew out >of a port of Red Hat to the PowerPC Mac which of necessity needed its >own universe), and it allowed integration on the client of multiple >repository sources. Yum offered the ability to install and update from >the repositories listed. Fedora recently managed to consolidate an >external package repository, and they seem to be trying to grapple with >this problem, but with Yum they at least have a way ot combining them at >the client. > >Unfortunately, since there is no authoritative source for the RPM >packaged version of some library (cross-indexed with a release and >status as with Debian), there is no single set of compile-time options >in use. As en example, until recently, Fedora users couldn't install >W1HKJ's fldigi with the default fltk RPM file on which it depends >because Dave's coded needed the --with-threads option required in fltk >at compile time. > >The job of a Linux distribution is to pick in time a set of package >versions and instances of them compiled with flags, and make sure (QA) >that they work together. RedHat paid people to do this. Debian threw >together a tree of "latest" and encourged people to file & fix >dependency problems. Neither model scaled well. Recently, the Debian >and Red Hat worlds got closer, as Debian has downstream providers such >as Ubuntu, who pay people to do more testing, integration, and tuning, >and more like SuSE with lots of attention to the installer. >RedHat/Fedora became more like Debian by relying more on a dedicated >(but increasingly disenchanted) community to do testing of frequent >releases. > >So, the upshot of all this is that both Debian's format and the RPM/Yum >system do a good job of capturing dependencies and providing an >environment to resolve them in, but neither can work without people >compiling nd cross-testing the packages that they put into their >respective repositories. With Debian, the path upstream is a little >clearer so it is a little easiser to figure out where to put things, but >the "download this from a website and install the package" option is >much harder (partially because they don't want you to do that -- put it >in the repository instead). > >All this being said, there is something called "alien" which will >convert from .deb to .rpm format, but that doesn't at all take into >account that the packages and packagings and patches in the two systems >(deb's in a system, rpm's is a federation) don't align. > >73, >Leigh/WA5ZNU > > >
