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 at gmail.com