On 4/6/11 6:09 PM, Karanbir Singh wrote:
Other repo's _may_ respect upstream and not overwrite base packages or create conflicts. However, they aren't going to consider CentOS "upstream". And I think there is evidence that what is right for them is not going to be right for Centos users that have base/extra/plus packages that don't match or conflict with what they consider upstream.
For a lot of these packages, there does not need to be an upstream concept if its project to project delivered. The centos.org repo's become a delivery mechanism to the centos userbase for a specific app in sync with what that app developers consider as their own policy ( and we can help them with the centos side of things )
I'm not sure why an app developer would think a specialized package exclusively for CentOS would be desirable - and that idea seems like a particularly hard sell when the only goal for CentOS is binary compatibility with upstream.
So, yes, unless you want to ensure conflicts with the repos that CentOS users depend on, you need a policy that minimizes collisions.
There is very little or no coordination between repo's - and honestly, the only real issue we'd be looking to solve would be for the centos userbase, not SL/RHEL/anyone-else. And its unlikely to be a mass package dump.
The lack of coordination is exactly my point. Unless you can provide every package that CentOS users will ever need, it becomes very likely that there will be people solving that same problem for RHEL/SL/etc. with packages with the same name, leapfrogging version numbers, and different and incompatible compile/config options in another repository that many CentOS users will need to have installed and active. Maybe CentOS- could be part of the package name, but filename conflicts would still happen.
-- Les Mikesell lesmikesell@gmail.com