Overlap policy v20120615

inode0 inode0 at gmail.com
Fri Jun 15 18:54:00 UTC 2012

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.


More information about the epel-devel-list mailing list