[CentOS-devel] Why not a fusion between CentOS and SL?
n3npq at mac.com
Thu Mar 24 16:29:49 EDT 2011
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.
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
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
More information about the CentOS-devel