> What's wrong with that? Some things depend on each other, and should be installed > at the same time, but shouldn't necessarily be the same package. Some people > have no concept of rpm -Uh <package1> <package2> yes, but I was using an apt-like tool (grab) which normally *would* deal with those dependencies; and even circular dependencies; but broke on those packages. dependency resolution is not an easy thing to get right; and RPM hasn't had a huge need for it until lately, so they didn't test the packages against automated-upgrade systems. I'm told that up2date used to have a good number of special-case hacks in it, to make things work properly with the packages which were available when it first came out; but that's just a 3rd-hand rumor. > You don't notice that debian does the same thing because you're using apt, > if you use apt under redhat it does the same deps resolution for you (as does > up2date, and the various other frontends to RPM) as I mentioned above; dependency resolution isn't trivial; it may be in the simple cases, but the corner cases will bite you, and those corner cases were usually the result of bad packaging. RPMs have definitely gotten better over the years. When there's a dependency issue in apt4rpm (usually just installing too many unnecessary dependencies), it's often a problem with a custom package built here at Real-Time; but not always. > > were there problems with the tool? yes. even so, this was very irritating, > > and poor form to change packages like that in a minor release, IMHO. > That's not an issue with a tool, it's user error =) no, this was a problem with the combination of 'grab', and packages that weren't properly tested with an auto-upgrade tool. the user (me) got around it by dealing with the packages directly, instead of with the auto-update/upgrade tool. (one of the nice things about grab, is that it'll let you force it to do something, even when it doesn't think it's a good idea. apt simply refuses to work in the face of broken dependencies; which may be good for most situations; but there are times that the administrator needs to override the tool and say 'I know what I'm doing, shoot me in the foot anyway'. Grab would work on systems with broken dependencies; which was a lot of them before apt4rpm came along.) > > at least we don't see packages from RH that need to be built as root. (one > > shouldn't be root when compiling an RPM; but I'm sure I saw one or two > > examples of that back in the RH6.2 days). > 6.2 is ancient =) yes, but the point I was making there, was that RPM quality-control used to suck; and now it sucks less. :) I'm not totally opposed to your viewpoint. :) Carl Soderstrom. -- Systems Administrator Real-Time Enterprises www.real-time.com _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list