EPEL Port oat package into

[Wei, Gang]

Hi,

I am porting oat package into EPEL, but when I try to build it in koji via:
$ Koji build --scratch --arch-override x86_64 el6-candidate
oat-1.6.0-9.fc16.src.rpm

I got:
DEBUG util.py:264:  Error: No Package found for sun-codemodel

I can find sun-codemodel package in 'jbappplatform-6-x86_64-server-6-rpm'
channel in RHN, why can't it be found during the koji build process?

Thanks
Jimmy

[Christopher Meng]

RHN is RHN, but not EPEL.

http://pkgs.org/search/?keyword=sun-codemodel

[Chen, Wei D]

Hi Christopher,

Is it possible for us to open RHN channel within koji build server? if true, how to? would you kindly give us some example?

Best Regards,
Dave Chen
> -----Original Message-----
> From: Christopher Meng [mailto:[e-mail]]
> Sent: Tuesday, July 30, 2013 11:12 AM
> To: EPEL Development List
> Cc: Xu, Quan; Chen, Wei D
> Subject: Re: EPEL Port oat package into
>
> RHN is RHN, but not EPEL.
>
> http://pkgs.org/search/?keyword=sun-codemodel

[T.C. Hollingsworth]

On Mon, Jul 29, 2013 at 8:22 PM, Chen, Wei D  wrote:
> Is it possible for us to open RHN channel within koji build server? if true, how to? would you kindly give us some example?

No.  Again, Fedora EPEL packages can only depend on packages from the
base and optional RHN channels, since we can't expect EPEL users to
pay for/subscribe to every additional channel under the sun.  Or they
might be using CentOS or Scientific Linux, which are fully supported
by EPEL but don't have all the channels available in RHEL.

If you need dependencies that are present in RHN channels besides base
or optional, you'll need to package them in EPEL.

-T.C.

[Kevin Fenzi]

On Tue, 30 Jul 2013 08:44:42 -0700
"T.C. Hollingsworth"  wrote:
> On Mon, Jul 29, 2013 at 8:22 PM, Chen, Wei D 
> wrote:
> > Is it possible for us to open RHN channel within koji build server?
> > if true, how to? would you kindly give us some example?
>
> No.  Again, Fedora EPEL packages can only depend on packages from the
> base and optional RHN channels, since we can't expect EPEL users to
> pay for/subscribe to every additional channel under the sun.  Or they
> might be using CentOS or Scientific Linux, which are fully supported
> by EPEL but don't have all the channels available in RHEL.
>
> If you need dependencies that are present in RHN channels besides base
> or optional, you'll need to package them in EPEL.

It's actually base os, optional, ha and lb. :)

But yes, there's no other channels used or added.

kevin

[Wei, Gang]

Christopher Meng wrote on 2013-07-30:
> RHN is RHN, but not EPEL.
>
> http://pkgs.org/search/?keyword=sun-codemodel

So can't EPEL package have build/run dependency on RHEL/RHN packages?

Jimmy

[Christopher Meng]

Well I think RHN is not open for EPEL.

So no answer. ;)

Unless you package it into Fedora EPEL.

[T.C. Hollingsworth]

On Mon, Jul 29, 2013 at 8:23 PM, Wei, Gang  wrote:
> Christopher Meng wrote on 2013-07-30:
> > RHN is RHN, but not EPEL.
> >
> > http://pkgs.org/search/?keyword=sun-codemodel
>
> So can't EPEL package have build/run dependency on RHEL/RHN packages?

Only the base and optional channels.  EPEL packages cannot depend on
other channels, since everyone might not subscribe to them.

-T.C.

[Wei, Gang]

T.C. Hollingsworth wrote on 2013-07-30:
> On Mon, Jul 29, 2013 at 8:23 PM, Wei, Gang  wrote:
> > Christopher Meng wrote on 2013-07-30:
> > > RHN is RHN, but not EPEL.
> > >
> > > http://pkgs.org/search/?keyword=sun-codemodel
> >
> > So can't EPEL package have build/run dependency on RHEL/RHN packages?
>
> Only the base and optional channels.  EPEL packages cannot depend on
> other channels, since everyone might not subscribe to them.

Thanks for the answer, it makes sense to me.

Jimmy

[T.C. Hollingsworth]

On Jul 29, 2013 8:31 PM, "Wei, Gang"  wrote:
> Thanks for the answer, it makes sense to me.

No problem. :-)

I forgot to mention that the flip side of this is that those are also the
only channels that EPEL is forbidden to conflict with. You're free to
package the dependencies you need in EPEL if you so desire.

I'm not sure if that's possible in your case since JBoss is a behemoth, but
I figured I'd mention it anyway. ;-)

-T.C.