On Sat, Dec 14, 2002 at 01:09:06AM +0800, Andy Sy wrote: > > 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.
A package manager enforces policies. The package format is merely an extension of it. Which is why your assertion that you'd mess up the dependency tree should you override policy - isn't that what happens when you disregard policy? (ex. it's perfectly valid to dereference a null pointer - but you mess up your app as a result since you're not following policy) > > 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. Actually, its the package management system which does this for you. For free. Unless you deliberately break the policy enforced by the software. > 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! Expect that if you hit something real hard, it'll break somehow. But there's a way for you not to screw up your package-managed software, see way below. > 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). This is a valid assertion, and is quite perplexing. Which is probably why some quarters moved for LSB certification. I also remember reading something in gcc.gnu.org regarding how to configure the compiler build so that the binaries it would produce would be "compatible?" (I'm not sure of the term... please refresh me) There was old news back then that there was a time wherein you could just pick up an rpm and it would install unto any distro without hitches? For the old timers - was this true (somehow, or for a majority)? > > 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. That's RedHat's policy. They have the prerogative to roll out their own packages. Caveat emptor. I'm not really sure if there's a way to offset that in RPM-based distros (the mere fact that I'm not using one is already a give-away that I'm clueless on what more powers RPM has for me to experiment on). > 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. Yeah, quite true. Unless you can expand the official packager base of your distribution of choice, this would certainly remain a problem (Debian somehow offsets much of this problem, since in Debian they have a very stringent process in their distribution). Slackware - the policy in package management is no policy. So you can roll out your own tarball. Just be mindful of the software's dependencies (and watch out also what compiler was used in compiling the package - especially with developer packages such as compilers and libraries - you may end up with ABI-incompatible stufff -> leaving those packages quite useless lest you roll out another or find a compatible one). Same checks would have to be considered especially with contributed packages (not officially endorsed by your distro). > 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. Then again it isn't always wise to ignore them. You can get away with installing a slackware tgz without minding the dependencies - but is there a full assurance that it would even run properly in the first place? Without a package management system, instead of the package manager deciding for you, you're basically on your own. If you break policy (assuming there's package management policy) then that's your fault. > 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. > As I've said, that's their policy. Fortunately Slackware doesn't have those restrictions - with a tradeoff that _you_ will have to do the thinking. Acceptable to some, not acceptable to some other people. > > '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. When I was still using Debian Potato, slackware packages were quite a blessing for me as I can roll updated software in /usr/local then play with it [after satisfying the needed dependencies - if the software requires it]. However, unless you'll stick with that version for the rest of your computing life, you'll want to somehow update/upgrade. Then the lack of policy (or even breaking it) becomes a real pain. You'll be forced to retrace what packages you installed, then use more braincycles to figure out how to get rid of them without breaking other software. Unless you practice proper accounting of software (which I think a Slackware user should diligently practice), it will really be a pain. > 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. You can get away by installing your custom apps in /usr/local. It won't break an existing policy (FHS forbids package management software to screw with /usr/local). Whatever you do there, you're basically on your own. -- Paolo Alexis Falcone [EMAIL PROTECTED] _ 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]
