On Mar 24, 2011, at 4:13 PM, Lamar Owen wrote: > On Thursday, March 24, 2011 02:40:59 pm Jeff Johnson wrote: >> But priority in the "real world" of multiple repositories is too arbitrary >> and not based on intrinsic details like dependency closure and difficult >> to administer reliably: >> Who *exactly* chooses the priority? What criteria are the basis? > > Well, Jeff, it partially goes all the way back to a subject related to a discussion you and I had years ago, in Red Hat 6.1/6.2 timeframes, of why PostgreSQL database data upgrades couldn't be done in %pre, %install, %post, or %postun scriptlets. We had been talking about the anaconda chroot and some of the deficiencies of that chroot and how the environment wasn't stable enough to do the ambitious things I wanted to do, and you made a statement along the lines that all RPM knows is packages; it doesn't know squat about distributions, just packages. > Well my comments way back when were based on real world experience attempting to automate postgresql database format conversions. That was actually attempted in RPM scriptlets (RHL5.2? I fergit) and turned out to be rather a disaster with ENOSPC failure conditions. (aside) These days sqlite3 is embedded @rpm5.org, so its quite possible to do a full dump/reload operation now that "disk space is cheap". But the salient point is that RPM is a pretty stoopid program, implements mechanism but not policy, and largely does whatever its told to do. That's merely a restatement of "... doesn't know squat about distributions ..." > Substitute repositories for distributions, and you have today's situation. RPM itself doesn't care where a package gets its dependencies from, just that they're satisfied. > Depends on POV. The operant POV is rpm == dpkg which is no more accurate than rpm == apt RPM is a weird mixture between apt (and depsolvers) and dpkg (and archiver operations). (aside) RPM @rpm5.org is tracking not only the *.rpm file digest, but also the origin/stat(2) of the original *.rpm file, and ghas many other features that aren't "doesn't care". But you are likely quoting a statement from me that If two packages have the same Provides:, either will do. That's merely a statement of logic: the Requires: assertion will have an identical truth table no matter which package is chosen. But "preference" and installer "policy" isn't well implemented anywhere that I see. Sure there's "repositories" and "applications" and "distros", but there isn't any implementation of "preference". Go ask for Suggests: to be implemented in RPM and listen carefully to the random replies. Everyone wants "preference", but there's no meaningful (afaics) implementation around. It *is* a non-trivial problem to solve. > I'm going to have to look up that e-mail, because I know I kept it....and I'm fairly certain it was you, but it might have been someone else, might have even been Nottingham. > "Patience grasshoppers" still cracks me up (but I have a warped sense of humor) >> And freshrpms was wonderful and Matthias is truly a gentleman, his involvement >> is missed. > > Yes, it is. > >> But everyone moves on to other interests than Linux eventually. > > Indeed. If it weren't my 'daily driver' OS I might not still be around these parts. And if it wasn't for an RPM fork (which pissed me off: I have no intent of "losing") I'd likely have moved on to something else too. 73 de Jeff > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel