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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel