> I may choose to say, hey system, SCREW YOUR DEPENDENCIES and simply do a > > rpm -Uvh ---nodeps --force package-ver.i386.rpm > > Or i may choose to say , 'Oh really'... and do a 'urpmi'
Ah but this is my problem, the moment you insert your own packages and ignore the dependency tree, you mess it up unless you take pains to ensure consistency. And, in my experience these inconsistencies tend to snowball. When I was starting out, I had the illusion that as long as it's an rpm it's going to fit nicely into any system that supports such. I learned the hard way that it doesn't work like that. A dependency tree DOES NOT COME FOR FREE. You have to exert effort in pruning and maintaining it. In fact it is the sort of effort that makes the job of a package/distro maintainer a fulltime one. You can always choose to ignore dependencies and it won't mean that things will fail to work, but you will end up getting a lot of annoying error messages regarding broken dependencies when you try to mix and match stuff from different sources. To avoid these messages, you basically have to turn off dependency checking (something you will grow to do more and more often unless you're willing to do the hard work of resyncing your dependency labels with those of RH, an O(mn) job) thus defeating the whole idea of having dependencies in the first place! If you're using a Redhat distro then you have to get all your rpms from Redhat and only Redhat and often ONLY the proper rpm for the correct RH version in order to avoid chaos (that's why you see different rpms of the same package for different versions of RH). Now what makes this situation really sucky is the fact that if you really need to try out a certain software right now which is not yet available as rpm from Redhat, you can opt to roll your own rpm. HOWEVER... when Redhat comes out with their newer version, you have no guarantee that it's going to have the same dependency label as that you assign to your package. When you try to compile something like a new version of X, there is a virtually 100% chance that it will require a lot of stuff from different sources which Redhat may not have yet made available. Thus you are basically grafting on a new branch in your dependency that is not 'Redhat blessed'. If one of the leaves in those branches is released by Redhat later and other RH packages depend on it, you had better happen to have assigned the same dependency label to it as the one Redhat chose. If you didn't, and the chances are pretty good that such is the case... well then, you're gonna find yourself futzing around endlessly trying to get the labels right both for that package and ALL the other packages that depend on it. This is the pain of having dependencies. You might think that you won't have these problems because you don't install monolithic packages like X, but you will still find yourself doing this dependency dance when you try to install stuff like, say AA support for X, which might depend on a newer version of Freetype (just a hypothetical scenario) which might in turn depend on something else... you get the picture. It's hard enough making sure the library versions match, but bring in dependency labels into the mix and the situation quickly becomes hopeless. Moreover, in Redhat's case, I find that this effective requirement for your rpms to come from a single source (under the threat of a messy system) to be rather disingenuous towards the ideals of open source. > 'Best practices' always should include selecting > distributions with mature package management, with > a very dynamic package development team. This > makes the systems deployed using it up to date, > more maintainable and much easier to administer. If you know you're never or only very rarely going to diverge from a distro's set of packages, then dependencies do make your life a bit easier. Just a little, imo, because once you have learned how to roll your own Slackware tarballs, it's really quite easy, and having to understand what packages depend on which is information that almost always ends up being vital anyway, so you might as well learn it during install time. And the moment you find yourself wanting to install a version of a software that is not yet released in your distro package format and it happens to depend on something else which isn't too, then the serious disadvantages of having to maintain your own set of dependencies independent of the distro makers' will start making themselves felt. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
