I would add as a benefit that past experiences have taught us that at times,
packages in EPEL may be included in new minor RHEL releases, and would
therefore need to be dropped from EPEL.
In any case, +1 from me.
___
epel-devel mailing list -- epel-dev
I want to make sure I'm reading this right.
A packager puts a package into EPEL.
If the user does nothing, that package continues to be in EPEL.
If the user wishes to end support, they sent off and email, compose
one final build (if it can compose), wait for it to land, then send
off another email.
On Fri, Feb 15, 2019 at 09:45:01AM -, Jeroen van Meeuwen wrote:
> I would add as a benefit that past experiences have taught us that at
> times, packages in EPEL may be included in new minor RHEL releases, and
> would therefore need to be dropped from EPEL.
In the future, we won't necessarily
On Fri, 15 Feb 2019 at 09:39, Troy Dawson wrote:
>
> I want to make sure I'm reading this right.
> A packager puts a package into EPEL.
> If the user does nothing, that package continues to be in EPEL.
> If the user wishes to end support, they sent off and email, compose
> one final build (if it c
On Fri, Feb 15, 2019 at 8:34 AM Stephen John Smoogen wrote:
>
> On Fri, 15 Feb 2019 at 09:39, Troy Dawson wrote:
> >
> > I want to make sure I'm reading this right.
> > A packager puts a package into EPEL.
> > If the user does nothing, that package continues to be in EPEL.
> > If the user wishes
On Fri, 15 Feb 2019 at 11:45, Troy Dawson wrote:
>
>
> Yes it does.
> Do we want to put anything in about packages that no longer install
> due to updates. Whether those updates are in EPEL or RHEL.
> An example would be when EPEL7 nodejs goes to nodejs 8 (or 10),
> There will be a handful of p