[CentOS-devel] Why not a fusion between CentOS and SL?

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