EPEL rhel-extras

[Kevin Fenzi]

Greetings.

One thing I missed in the RHEL7 release was that there is a repository
now called 'rhel-extras'.

For RHEL6 this contains upgrade packages (for in place rhel6->rhel7
upgrades).

For RHEL7 this contains (for now) docker and a number of flask packages
that docker-registry needs.

The policy for this repo is:
https://access.redhat.com/site/support/policy/updates/extras/

I'd like to propose that we include this in EPEL7 at least as a repo
that we don't conflict with (ie, as packages are added there, they are
retired from epel). CentOS will be building these packages as part of
it's base collection I think.

If packages in that repo prove too fast or too slow moving, we can look
at adding parallel installable versions of packages in there in EPEL.

Thoughts?

kevin

[Stephen John Smoogen]

On 16 June 2014 12:10, Kevin Fenzi  wrote:
> Greetings.
>
> One thing I missed in the RHEL7 release was that there is a repository
> now called 'rhel-extras'.
>
> For RHEL6 this contains upgrade packages (for in place rhel6->rhel7
> upgrades).
>
> For RHEL7 this contains (for now) docker and a number of flask packages
> that docker-registry needs.
>
> The policy for this repo is:
> https://access.redhat.com/site/support/policy/updates/extras/
>
> I'd like to propose that we include this in EPEL7 at least as a repo
> that we don't conflict with (ie, as packages are added there, they are
> retired from epel). CentOS will be building these packages as part of
> it's base collection I think.

I agree. Is there a way we could (if we wanted to) tie checks with what is
in git.centos.org? If it is there then its going to be in the upstream
somewhere and would allow us to avoid some conflicts.
> If packages in that repo prove too fast or too slow moving, we can look
> at adding parallel installable versions of packages in there in EPEL.
>
> Thoughts?
>
> kevin
>
> epel-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[Michael Stahnke]

> > The policy for this repo is:
> > https://access.redhat.com/site/support/policy/updates/extras/
> >
> > I'd like to propose that we include this in EPEL7 at least as a repo
> > that we don't conflict with (ie, as packages are added there, they are
> > retired from epel). CentOS will be building these packages as part of
> > it's base collection I think.

+1.

Is there need for tooling to ensure this is the case, or can we reuse
something that already exists?
> >

[Kevin Fenzi]

ok, not much discussion here, but it seems like everyone is ok with
just saying rhel-extras is something we don't conflict with.

Thanks,

kevin

[Michael Stahnke]

On Wed, Jun 25, 2014 at 8:12 AM, Kevin Fenzi  wrote:
> ok, not much discussion here, but it seems like everyone is ok with
> just saying rhel-extras is something we don't conflict with.

One question I have is how long this decision is valid for. Right now, I
think the proposal is the best decision. 3 years from now, we may have
different opinions. 7 years from now, we really might. Does this decision
last the 10 years that RHEL does or can we revisit at some point, if
required?

[Stephen John Smoogen]

On 25 June 2014 11:27, Michael Stahnke  wrote:
> On Wed, Jun 25, 2014 at 8:12 AM, Kevin Fenzi  wrote:
> > ok, not much discussion here, but it seems like everyone is ok with
> > just saying rhel-extras is something we don't conflict with.
>
> One question I have is how long this decision is valid for. Right now, I
> think the proposal is the best decision. 3 years from now, we may have
> different opinions. 7 years from now, we really might. Does this decision
> last the 10 years that RHEL does or can we revisit at some point, if
> required?

Good question.. and leads into my next email about EPEL.next... what do
people see as the challenges and future of EPEL.