> just to clarify for those less familiar w/Linux, RPM is *NOT* Red Hat > specific. RPM is part of the Linux Standards Base (LSB) and describes a > package management file format. RPM debuted on Red Hat (though even it was > based on prior work) but is today used by SuSe, Mandrake, SCO (previously > Caldera), Connectiva, Lycoris, Lindows, Ark, Kondara .. (shall i go on? =)
Heck, just to clarify for me. I didn't know that. I knew it wasn't just RH anymore but I didn't know RPM was part of the LSB spec. > rpm -U ... rpm -i only for things like kernels which you don't upgrade by > overwriting the binaries... and Red Hat can't brag about being user friendly > re: downloading rpms because they've fallen behind every other modern > distribution when it comes to package delivery (YAST, urpm*, apt-get...) Isn't -U to upgrade rather than install? Isn't delivery easy if you pay for it, via up2date, or whatever? > please don't confuse package file formats with package delivery systems. the > two work together to solve completeley different aspects of the software > maintenance challenge. But from a user's perspective these end up being the same thing. For getting software onto one system you do X. To get it on another you do Y. This person was asking about differences between distros, and what I said is that if you take the source, and configure, make, and install it, it works the same for them all. The difference is if you use any of the distro specific tools. You don't need to. There is a lowest common denominator that works everywhere. > > And you can compile on one machine for another. So if your Caldera box is > > a 486/66, and your Sorceror box is an Athlon 3000+, then you can use the > > Sorceror box to compile the packages on the Caldera box. No, Sorceror > > probably won't build you an easily installable package, but it can compile > > from source in exactly the same manner as it would happen on the Caldera > > box (plus some extra steps to chroot, and stuff.). These aren't > > given enough effort (you'd have to ensure a compatible toolchain and package > management solution used for the build in question) it is completely possible > to build such packages. of course, it's often easier to simply build it on > the target system rather than create a complex build environment =) Again, yes, this would be a heck of a job, but the point I was making was that Linux is Linux. The systems can work together. The distros are designed to do things their own way (heck, even the file system layouts are sometimes different) but the end result is that they can all work together because they all work in the same way if you just ignore all the disto specific stuff, and build from source. And I'm not saying that's the best way either. I do understand what will happen if some packages are installed from source, and some aren't, and then the system is upgraded. :) It'll break. Kev.
