Overlap policy v20120615

Stephen John Smoogen smooge at gmail.com
Fri Jun 15 19:06:26 UTC 2012


On 15 June 2012 12:54, inode0 <inode0 at gmail.com> wrote:
> On Fri, Jun 15, 2012 at 1:41 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
>> On 06/15/2012 11:43 AM, inode0 wrote:
>>>
>>> On Fri, Jun 15, 2012 at 12:34 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>>>>
>>>> On Fri, 15 Jun 2012 12:27:30 -0500
>>>> inode0 <inode0 at gmail.com> wrote:
>>>>>
>>>>>
>>>>> I'm sorry if this has been answered before and I have forgotten the
>>>>> answer but why are the lb and ha bits excluded? Was there a request
>>>>> from the RHEL side to exclude them?
>>>>
>>>>
>>>> They were added to our buildsystem a while back because they contained
>>>> dependencies that were used by epel packages. There wasn't a formal
>>>> request that I know of, but it was requested by several maintainers.
>>>>
>>>> I suppose we could look at dropping them.
>>>
>>>
>>> No, I don't want them dropped from the build system. I want to know
>>> why piranha can't be packaged by EPEL for example?
>>
>>
>> Well, piranha is shipped by ScientificLinux (and probably CentOS),
>> presumably because the srpm is in 6Server, so you would end up with
>> conflicts there.  If you are a paying RedHat customer and want support,
>> presumably you would purchase the relevant channel as well to get piranha?
>
> Oh, I missed the EPEL does not conflict with packages shipped by CentOS rule?!
>
> Some paying RHEL customers use the two packages for LB from CentOS now
> and would rather use them from EPEL. This is not a logical reason to
> treat lb and ha differently from anything else CentOS might ship. Not
> to mention RHEL users who get puppet from EPEL when they could pay Red
> Hat for that too. My problem is mostly just that this seems completely
> arbitrary to me.

Well of course it is arbitrary. Any definition we use is going to be
arbitrary because well there is no rock solid proof that says "this is
RHEL" and "this isn't RHEL". Expecting us to define that definition
when it is clear that even Red Hat has no rock solid definition is
preposterous. So this is our arbitrary line in the sand. It is no
better or worse than if we drew it 2 feet to the left or 2 feet to the
right. However until the tide comes in and washes it away, this is the
one we are looking to use.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd




More information about the epel-devel-list mailing list