[CentOS-devel] Why not a fusion between CentOS and SL?
Jeff Johnson
n3npq at mac.com
Thu Mar 24 20:29:49 UTC 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.
(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
More information about the CentOS-devel
mailing list