Re: Re: are RPMForge and EPEL compatible?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Stephen John Smoogen wrote:
On Dec 6, 2007 12:51 PM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
Stephen John Smoogen wrote:

The point is that as an end user, I want a sensible way to deal with
multiple repositories that _don't_ collaborate.  After all, if everyone
agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different repositories, using
M different guidelines, using O different compile flags, and P
different filesystem layouts.
The constraint is simply that you do not replace any file/library with
one that is incompatible.

And how do you know it isnt compatible? Keeping ABI's the same is
extremely hard work and basically would mean that a repository rarely
puts up new stuff but only backports items from upstream. Thats a lot
of work for something they don't get paid for. And even if the ABI is
the same, it doesnt mean that you have different actions occur because
one had a compiler with XYZ flag in it and the other had XZY.

The Sun people like to claim that you can run
anything that ever ran on Solaris on subsequent versions so the problem
space isn't as impossible as you make it seem - it is more a matter of
respecting interfaces and backwards compatibility.

And that was a load of bull from Solaris. You could run most Sun
things from Solaris 2.x to 2.x1 but the list of things that didn't run
as expected was always pretty long. And to do that they had to
basically strip down the OS to extremely limited functionality. That
was why it was such a 'radical' change when they started shipping GNU
tools in the OS because it had been requested for years but the amount
of churn was too high for them to want to deal with.

But my point is that
I don't want to be forced to use a repository that always follows this
constraint.  Sometimes compatibility is what you want, sometimes you
want something different, and you need to be able to manage both.


But are you willing to pay for that? Because its not an easy problem
to solve that people can throw more computers at and get it working.
It usually requires a lot of meat-ware time with people working out
meat-ware politics and issues.

The best you could possibly do is not
have packages at all but keep each package in a dmg file and let the
ld fight it out over who gets executed today... but that would seem to
be a different OS.
Yes, that would make Linux as difficult to maintain as a Mac.


Maintainability is usually on the opposite side of choices.




guys, while somewhat relevant - this list is really not the place for this conversation. As has happened before its going to go round in circles with lots of noise - but no action.

--
Karanbir Singh : http://www.karan.org/  : 2522219@icq
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux