1:01 p.m.
Hello everyone,
There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
nice EOL overview:
* Puppet 3 - 2016-12-31
* Puppet 4 - 2018-10-??
* Puppet 5 - 2021-02-??
Puppet 6 requires a newer Ruby version than is available in EL7 so
rebasing the whole stack is not going to work. In theory you could use
SCLs but I think it's unrealistic to expect that.
However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
what to do.
We can close all bugs as WONTFIX (including the security ones), but
would it be better to also remove the package from EPEL-7?
Regards,
Ewoud Kohl van Wijngaarden
[1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
1:49 p.m.
On Tue, Apr 26, 2022 at 2:10 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
Hello everyone,
There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
nice EOL overview:
* Puppet 3 - 2016-12-31
* Puppet 4 - 2018-10-??
* Puppet 5 - 2021-02-??
Puppet 6 requires a newer Ruby version than is available in EL7 so
rebasing the whole stack is not going to work. In theory you could use
SCLs but I think it's unrealistic to expect that.
Rebuild it with the sco packages, namely rh-ruby25 ?
> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
> what to do.
>
> We can close all bugs as WONTFIX (including the security ones), but
> would it be better to also remove the package from EPEL-7?
>
> Regards,
> Ewoud Kohl van Wijngaarden
>
> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
3:48 p.m.
On Tue, Apr 26, 2022 at 02:49:26PM -0400, Nico Kadel-Garcia wrote:
On Tue, Apr 26, 2022 at 2:10 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>
> Hello everyone,
>
> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> nice EOL overview:
>
> * Puppet 3 - 2016-12-31
> * Puppet 4 - 2018-10-??
> * Puppet 5 - 2021-02-??
>
> Puppet 6 requires a newer Ruby version than is available in EL7 so
> rebasing the whole stack is not going to work. In theory you could use
> SCLs but I think it's unrealistic to expect that.
Rebuild it with the sco packages, namely rh-ruby25 ?
I'll state that I have extensive SCL knowledge, after working with it in
packaging Foreman. With that I'll clarify why I think it's unrealistic.
The primary reason is that I have no interest nor use for it at all.
Right my last EL7 machine is using the Puppet AIO package and I'll phase
it out soon.
Second, I don't know if anyone has done this and what the effects will
be. Providers such as the gem package provider will behave different.
You also won't have access to any Ruby gems that you may have installed.
As such it'll be a massive non-trivial migration for any user.
Speaking of gems, you will need to build all the dependent gems in the
SCL. This means a lot of gems need to be modified and released. From
experience I can tell you there are many things you can easily mess up,
as well as bugs in the SCL stack you need to work around (BZ1995018
being particularly nasty). Which brings me back to my primary reason: I
have no time for this.
BZ1995018: https://bugzilla.redhat.com/show_bug.cgi?id=1995018
7:37 p.m.
I believe it may be time to retire puppet from EPEL 7. The presented
reasons are fair in my opinion.
The el7 users can easily migrate over to higher versions either using the
self-contained package offered by Puppet Labs, or can install the
aforementioned rh-ruby26 and then install puppet >=6 via gem (gem install
puppet).
- Breno
On Tue, Apr 26, 2022 at 4:48 PM Ewoud Kohl van Wijngaarden <
ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
On Tue, Apr 26, 2022 at 02:49:26PM -0400, Nico Kadel-Garcia wrote:
>On Tue, Apr 26, 2022 at 2:10 PM Ewoud Kohl van Wijngaarden
><ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>
>> Hello everyone,
>>
>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has
a
>> nice EOL overview:
>>
>> * Puppet 3 - 2016-12-31
>> * Puppet 4 - 2018-10-??
>> * Puppet 5 - 2021-02-??
>>
>> Puppet 6 requires a newer Ruby version than is available in EL7 so
>> rebasing the whole stack is not going to work. In theory you could use
>> SCLs but I think it's unrealistic to expect that.
>
>Rebuild it with the sco packages, namely rh-ruby25 ?
I'll state that I have extensive SCL knowledge, after working with it in
packaging Foreman. With that I'll clarify why I think it's unrealistic.
The primary reason is that I have no interest nor use for it at all.
Right my last EL7 machine is using the Puppet AIO package and I'll phase
it out soon.
Second, I don't know if anyone has done this and what the effects will
be. Providers such as the gem package provider will behave different.
You also won't have access to any Ruby gems that you may have installed.
As such it'll be a massive non-trivial migration for any user.
Speaking of gems, you will need to build all the dependent gems in the
SCL. This means a lot of gems need to be modified and released. From
experience I can tell you there are many things you can easily mess up,
as well as bugs in the SCL stack you need to work around (BZ1995018
being particularly nasty). Which brings me back to my primary reason: I
have no time for this.
BZ1995018: https://bugzilla.redhat.com/show_bug.cgi?id=1995018
9:03 p.m.
On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
Hello everyone,
There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
nice EOL overview:
* Puppet 3 - 2016-12-31
* Puppet 4 - 2018-10-??
* Puppet 5 - 2021-02-??
Puppet 6 requires a newer Ruby version than is available in EL7 so
rebasing the whole stack is not going to work. In theory you could use
SCLs but I think it's unrealistic to expect that.
However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
what to do.
We can close all bugs as WONTFIX (including the security ones), but
would it be better to also remove the package from EPEL-7?
Regards,
Ewoud Kohl van Wijngaarden
[1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Retiring epel7's puppet may be the preferred option. It is allowed
[0], but if you go this route please mention it on the epel-devel list
(and perhaps epel-announce) first.
Alternatively, have you considered doing an incompatible update [1] to
version 5? It may already be EOL, but surely that's a better option
than the current version 3 or removing it entirely.
[0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
[1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
--
Carl George
6:40 a.m.
On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>
> Hello everyone,
>
> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> nice EOL overview:
>
> * Puppet 3 - 2016-12-31
> * Puppet 4 - 2018-10-??
> * Puppet 5 - 2021-02-??
>
> Puppet 6 requires a newer Ruby version than is available in EL7 so
> rebasing the whole stack is not going to work. In theory you could use
> SCLs but I think it's unrealistic to expect that.
>
> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
> what to do.
>
> We can close all bugs as WONTFIX (including the security ones), but
> would it be better to also remove the package from EPEL-7?
>
> Regards,
> Ewoud Kohl van Wijngaarden
>
> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
Retiring epel7's puppet may be the preferred option. It is allowed
[0], but if you go this route please mention it on the epel-devel list
(and perhaps epel-announce) first.
I should have realized this, will bring it up there.
Alternatively, have you considered doing an incompatible update [1]
to
version 5? It may already be EOL, but surely that's a better option
than the current version 3 or removing it entirely.
The Ruby version in EL7 is simply too old. In theory you could write a
ton of patches to make it compatible again, but the Puppet modules users
have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
itself is already EOL (for more than a year), but packaging Puppet 6 vs
Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
a newer Ruby. After that it's all minor differences.
>[0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>[1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
8:07 p.m.
On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>
>> Hello everyone,
>>
>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
>> nice EOL overview:
>>
>> * Puppet 3 - 2016-12-31
>> * Puppet 4 - 2018-10-??
>> * Puppet 5 - 2021-02-??
>>
>> Puppet 6 requires a newer Ruby version than is available in EL7 so
>> rebasing the whole stack is not going to work. In theory you could use
>> SCLs but I think it's unrealistic to expect that.
>>
>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
>> what to do.
>>
>> We can close all bugs as WONTFIX (including the security ones), but
>> would it be better to also remove the package from EPEL-7?
>>
>> Regards,
>> Ewoud Kohl van Wijngaarden
>>
>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>
> Retiring epel7's puppet may be the preferred option. It is allowed
> [0], but if you go this route please mention it on the epel-devel list
> (and perhaps epel-announce) first.
I should have realized this, will bring it up there.
> Alternatively, have you considered doing an incompatible update [1] to
> version 5? It may already be EOL, but surely that's a better option
> than the current version 3 or removing it entirely.
The Ruby version in EL7 is simply too old. In theory you could write a
ton of patches to make it compatible again, but the Puppet modules users
have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
itself is already EOL (for more than a year), but packaging Puppet 6 vs
Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
a newer Ruby. After that it's all minor differences.
> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
> [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
Bundle a newer Ruby?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
6:09 a.m.
On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>>
>>> Hello everyone,
>>>
>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
>>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
>>> nice EOL overview:
>>>
>>> * Puppet 3 - 2016-12-31
>>> * Puppet 4 - 2018-10-??
>>> * Puppet 5 - 2021-02-??
>>>
>>> Puppet 6 requires a newer Ruby version than is available in EL7 so
>>> rebasing the whole stack is not going to work. In theory you could use
>>> SCLs but I think it's unrealistic to expect that.
>>>
>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
>>> what to do.
>>>
>>> We can close all bugs as WONTFIX (including the security ones), but
>>> would it be better to also remove the package from EPEL-7?
>>>
>>> Regards,
>>> Ewoud Kohl van Wijngaarden
>>>
>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>>
>> Retiring epel7's puppet may be the preferred option. It is allowed
>> [0], but if you go this route please mention it on the epel-devel list
>> (and perhaps epel-announce) first.
>
> I should have realized this, will bring it up there.
>
>> Alternatively, have you considered doing an incompatible update [1] to
>> version 5? It may already be EOL, but surely that's a better option
>> than the current version 3 or removing it entirely.
>
> The Ruby version in EL7 is simply too old. In theory you could write a
> ton of patches to make it compatible again, but the Puppet modules users
> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
> itself is already EOL (for more than a year), but packaging Puppet 6 vs
> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
> a newer Ruby. After that it's all minor differences.
>
>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
Bundle a newer Ruby?
RHEL 7 has published "software collection library" versions of ruby,
titled "rh-ruby25".
As somebody who's backported bulky software for RHEL based operating
systems, like Samba and current ansible and airflow and yes, years
ago, puppet, I don't recommend installing your own ruby. Resolving the
dependencies gets painful, fast.
6:27 a.m.
On Thu, Apr 28, 2022 at 07:09:41AM -0400, Nico Kadel-Garcia wrote:
On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> > On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> >> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> >> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> >>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has
a
> >>> nice EOL overview:
> >>>
> >>> * Puppet 3 - 2016-12-31
> >>> * Puppet 4 - 2018-10-??
> >>> * Puppet 5 - 2021-02-??
> >>>
> >>> Puppet 6 requires a newer Ruby version than is available in EL7 so
> >>> rebasing the whole stack is not going to work. In theory you could use
> >>> SCLs but I think it's unrealistic to expect that.
> >>>
> >>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm
wondering
> >>> what to do.
> >>>
> >>> We can close all bugs as WONTFIX (including the security ones), but
> >>> would it be better to also remove the package from EPEL-7?
> >>>
> >>> Regards,
> >>> Ewoud Kohl van Wijngaarden
> >>>
> >>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
> >>
> >> Retiring epel7's puppet may be the preferred option. It is allowed
> >> [0], but if you go this route please mention it on the epel-devel list
> >> (and perhaps epel-announce) first.
> >
> > I should have realized this, will bring it up there.
> >
> >> Alternatively, have you considered doing an incompatible update [1] to
> >> version 5? It may already be EOL, but surely that's a better option
> >> than the current version 3 or removing it entirely.
> >
> > The Ruby version in EL7 is simply too old. In theory you could write a
> > ton of patches to make it compatible again, but the Puppet modules users
> > have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
> > itself is already EOL (for more than a year), but packaging Puppet 6 vs
> > Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
> > a newer Ruby. After that it's all minor differences.
> >
> >> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
> >> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> Bundle a newer Ruby?
RHEL 7 has published "software collection library" versions of ruby,
titled "rh-ruby25".
As somebody who's backported bulky software for RHEL based operating
systems, like Samba and current ansible and airflow and yes, years
ago, puppet, I don't recommend installing your own ruby. Resolving the
dependencies gets painful, fast.
I agree you don't want to do that. And if you're going that route
anyway, why not use the official RPMs which do take that approach:
https://yum.puppet.com/
10:36 p.m.
On 4/28/22 07:09, Nico Kadel-Garcia wrote:
On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
>>>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
>>>> nice EOL overview:
>>>>
>>>> * Puppet 3 - 2016-12-31
>>>> * Puppet 4 - 2018-10-??
>>>> * Puppet 5 - 2021-02-??
>>>>
>>>> Puppet 6 requires a newer Ruby version than is available in EL7 so
>>>> rebasing the whole stack is not going to work. In theory you could use
>>>> SCLs but I think it's unrealistic to expect that.
>>>>
>>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm
wondering
>>>> what to do.
>>>>
>>>> We can close all bugs as WONTFIX (including the security ones), but
>>>> would it be better to also remove the package from EPEL-7?
>>>>
>>>> Regards,
>>>> Ewoud Kohl van Wijngaarden
>>>>
>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>>>
>>> Retiring epel7's puppet may be the preferred option. It is allowed
>>> [0], but if you go this route please mention it on the epel-devel list
>>> (and perhaps epel-announce) first.
>>
>> I should have realized this, will bring it up there.
>>
>>> Alternatively, have you considered doing an incompatible update [1] to
>>> version 5? It may already be EOL, but surely that's a better option
>>> than the current version 3 or removing it entirely.
>>
>> The Ruby version in EL7 is simply too old. In theory you could write a
>> ton of patches to make it compatible again, but the Puppet modules users
>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
>> itself is already EOL (for more than a year), but packaging Puppet 6 vs
>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
>> a newer Ruby. After that it's all minor differences.
>>
>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> Bundle a newer Ruby?
RHEL 7 has published "software collection library" versions of ruby,
titled "rh-ruby25".
As somebody who's backported bulky software for RHEL based operating
systems, like Samba and current ansible and airflow and yes, years
ago, puppet, I don't recommend installing your own ruby. Resolving the
dependencies gets painful, fast.
In that case, I would be fine with saying, “if you need to run Puppet
on RHEL 7, do so in a container or VM based on a newer RHEL”.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
10:49 p.m.
On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
On 4/28/22 07:09, Nico Kadel-Garcia wrote:
> On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
> <demiobenour(a)gmail.com> wrote:
>>
>> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
>>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
>>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
>>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has
been
>>>>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/
has a
>>>>> nice EOL overview:
>>>>>
>>>>> * Puppet 3 - 2016-12-31
>>>>> * Puppet 4 - 2018-10-??
>>>>> * Puppet 5 - 2021-02-??
>>>>>
>>>>> Puppet 6 requires a newer Ruby version than is available in EL7 so
>>>>> rebasing the whole stack is not going to work. In theory you could
use
>>>>> SCLs but I think it's unrealistic to expect that.
>>>>>
>>>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm
wondering
>>>>> what to do.
>>>>>
>>>>> We can close all bugs as WONTFIX (including the security ones), but
>>>>> would it be better to also remove the package from EPEL-7?
>>>>>
>>>>> Regards,
>>>>> Ewoud Kohl van Wijngaarden
>>>>>
>>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>>>>
>>>> Retiring epel7's puppet may be the preferred option. It is allowed
>>>> [0], but if you go this route please mention it on the epel-devel list
>>>> (and perhaps epel-announce) first.
>>>
>>> I should have realized this, will bring it up there.
>>>
>>>> Alternatively, have you considered doing an incompatible update [1] to
>>>> version 5? It may already be EOL, but surely that's a better
option
>>>> than the current version 3 or removing it entirely.
>>>
>>> The Ruby version in EL7 is simply too old. In theory you could write a
>>> ton of patches to make it compatible again, but the Puppet modules users
>>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
>>> itself is already EOL (for more than a year), but packaging Puppet 6 vs
>>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
>>> a newer Ruby. After that it's all minor differences.
>>>
>>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>>
>> Bundle a newer Ruby?
>
> RHEL 7 has published "software collection library" versions of ruby,
> titled "rh-ruby25".
>
> As somebody who's backported bulky software for RHEL based operating
> systems, like Samba and current ansible and airflow and yes, years
> ago, puppet, I don't recommend installing your own ruby. Resolving the
> dependencies gets painful, fast.
In that case, I would be fine with saying, “if you need to run Puppet
on RHEL 7, do so in a container or VM based on a newer RHEL”.
Puppet is not very useful in a container. It's a systems management
tool, so it's designed to manage the computer itself.
--
真実はいつも一つ！/ Always, there's only one truth!
6:20 a.m.
On Thu, Apr 28, 2022 at 11:49 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 4/28/22 07:09, Nico Kadel-Garcia wrote:
> > On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
> > <demiobenour(a)gmail.com> wrote:
> >>
> >> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> >>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> >>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> >>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
> >>>>>
> >>>>> Hello everyone,
> >>>>>
> >>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6
has been
> >>>>> EOL for ages now.
https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> >>>>> nice EOL overview:
> >>>>>
> >>>>> * Puppet 3 - 2016-12-31
> >>>>> * Puppet 4 - 2018-10-??
> >>>>> * Puppet 5 - 2021-02-??
> >>>>>
> >>>>> Puppet 6 requires a newer Ruby version than is available in EL7
so
> >>>>> rebasing the whole stack is not going to work. In theory you
could use
> >>>>> SCLs but I think it's unrealistic to expect that.
> >>>>>
> >>>>> However, all bugs open for Puppet relate to EPEL-7[1] so
I'm wondering
> >>>>> what to do.
> >>>>>
> >>>>> We can close all bugs as WONTFIX (including the security ones),
but
> >>>>> would it be better to also remove the package from EPEL-7?
> >>>>>
> >>>>> Regards,
> >>>>> Ewoud Kohl van Wijngaarden
> >>>>>
> >>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
> >>>>
> >>>> Retiring epel7's puppet may be the preferred option. It is
allowed
> >>>> [0], but if you go this route please mention it on the epel-devel
list
> >>>> (and perhaps epel-announce) first.
> >>>
> >>> I should have realized this, will bring it up there.
> >>>
> >>>> Alternatively, have you considered doing an incompatible update [1]
to
> >>>> version 5? It may already be EOL, but surely that's a better
option
> >>>> than the current version 3 or removing it entirely.
> >>>
> >>> The Ruby version in EL7 is simply too old. In theory you could write a
> >>> ton of patches to make it compatible again, but the Puppet modules
users
> >>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
> >>> itself is already EOL (for more than a year), but packaging Puppet 6
vs
> >>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you
need
> >>> a newer Ruby. After that it's all minor differences.
> >>>
> >>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
> >>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> >>
> >> Bundle a newer Ruby?
> >
> > RHEL 7 has published "software collection library" versions of ruby,
> > titled "rh-ruby25".
> >
> > As somebody who's backported bulky software for RHEL based operating
> > systems, like Samba and current ansible and airflow and yes, years
> > ago, puppet, I don't recommend installing your own ruby. Resolving the
> > dependencies gets painful, fast.
>
> In that case, I would be fine with saying, “if you need to run Puppet
> on RHEL 7, do so in a container or VM based on a newer RHEL”.
>
Puppet is not very useful in a container. It's a systems management
tool, so it's designed to manage the computer itself.
That did take a bit of giggling when I saw it.
"puppet-agent" is available, updated, from puppetlabs at
http://yum.puppetlabs.com/puppet/el/7/ . They even have a
"puppetlabs-release" repo to enable that repo in yum.
Maybe it's time to drop the obsolete EPEL version altogether? Or to
beg puppetlabs to publish an EPEL package themselves? I don't
currently have a subscription, so have little leverage with them these
days.
11:06 a.m.
On Fri, Apr 29, 2022 at 7:21 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Thu, Apr 28, 2022 at 11:49 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
>
> On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
> <demiobenour(a)gmail.com> wrote:
> >
> > On 4/28/22 07:09, Nico Kadel-Garcia wrote:
> > > On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
> > > <demiobenour(a)gmail.com> wrote:
> > >>
> > >> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> > >>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> > >>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> > >>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
> > >>>>>
> > >>>>> Hello everyone,
> > >>>>>
> > >>>>> There is an ancient version of Puppet in EPEL-7. Version
3.6 has
been
> > >>>>> EOL for ages now.
https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> > >>>>> nice EOL overview:
> > >>>>>
> > >>>>> * Puppet 3 - 2016-12-31
> > >>>>> * Puppet 4 - 2018-10-??
> > >>>>> * Puppet 5 - 2021-02-??
> > >>>>>
> > >>>>> Puppet 6 requires a newer Ruby version than is available
in EL7
so
> > >>>>> rebasing the whole stack is not going to work. In theory
you
could use
> > >>>>> SCLs but I think it's unrealistic to expect that.
> > >>>>>
> > >>>>> However, all bugs open for Puppet relate to EPEL-7[1] so
I'm
wondering
> > >>>>> what to do.
> > >>>>>
> > >>>>> We can close all bugs as WONTFIX (including the security
ones),
but
> > >>>>> would it be better to also remove the package from
EPEL-7?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Ewoud Kohl van Wijngaarden
> > >>>>>
> > >>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
> > >>>>
> > >>>> Retiring epel7's puppet may be the preferred option. It
is
allowed
> > >>>> [0], but if you go this route please mention it on the
epel-devel
list
> > >>>> (and perhaps epel-announce) first.
> > >>>
> > >>> I should have realized this, will bring it up there.
> > >>>
> > >>>> Alternatively, have you considered doing an incompatible
update
[1] to
> > >>>> version 5? It may already be EOL, but surely that's a
better
option
> > >>>> than the current version 3 or removing it entirely.
> > >>>
> > >>> The Ruby version in EL7 is simply too old. In theory you could
write a
> > >>> ton of patches to make it compatible again, but the Puppet
modules
users
> > >>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that
Puppet 5
> > >>> itself is already EOL (for more than a year), but packaging
Puppet
6 vs
> > >>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference:
you
need
> > >>> a newer Ruby. After that it's all minor differences.
> > >>>
> > >>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
> > >>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > >>
> > >> Bundle a newer Ruby?
> > >
> > > RHEL 7 has published "software collection library" versions of
ruby,
> > > titled "rh-ruby25".
> > >
> > > As somebody who's backported bulky software for RHEL based operating
> > > systems, like Samba and current ansible and airflow and yes, years
> > > ago, puppet, I don't recommend installing your own ruby. Resolving
the
> > > dependencies gets painful, fast.
> >
> > In that case, I would be fine with saying, “if you need to run Puppet
> > on RHEL 7, do so in a container or VM based on a newer RHEL”.
> >
>
> Puppet is not very useful in a container. It's a systems management
> tool, so it's designed to manage the computer itself.
That did take a bit of giggling when I saw it.
"puppet-agent" is available, updated, from puppetlabs at
http://yum.puppetlabs.com/puppet/el/7/ . They even have a
"puppetlabs-release" repo to enable that repo in yum.
Maybe it's time to drop the obsolete EPEL version altogether? Or to
beg puppetlabs to publish an EPEL package themselves? I don't
currently have a subscription, so have little leverage with them these
days.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
The last time I spoke to them, they had no interest in pushing packages to
EPEL.
They didn't use standard procedures to create RPM files, they didn't even
have the spec files for their packages back then (not sure if this has
changed).
That was a few years ago, when I pushed puppet 6 to EPEL 8, and later
upgraded Fedora's puppet to the 6th version as well.
I don't think that that has changed, but we can ask.
For now I believe that retiring puppet 3X from EPEL 7 is fine.
- Breno
4:16 p.m.
On 4/28/22 23:49, Neal Gompa wrote:
On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 4/28/22 07:09, Nico Kadel-Garcia wrote:
>> On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
>> <demiobenour(a)gmail.com> wrote:
>>>
>>> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
>>>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
>>>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
>>>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has
been
>>>>>> EOL for ages now.
https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
>>>>>> nice EOL overview:
>>>>>>
>>>>>> * Puppet 3 - 2016-12-31
>>>>>> * Puppet 4 - 2018-10-??
>>>>>> * Puppet 5 - 2021-02-??
>>>>>>
>>>>>> Puppet 6 requires a newer Ruby version than is available in EL7
so
>>>>>> rebasing the whole stack is not going to work. In theory you
could use
>>>>>> SCLs but I think it's unrealistic to expect that.
>>>>>>
>>>>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm
wondering
>>>>>> what to do.
>>>>>>
>>>>>> We can close all bugs as WONTFIX (including the security ones),
but
>>>>>> would it be better to also remove the package from EPEL-7?
>>>>>>
>>>>>> Regards,
>>>>>> Ewoud Kohl van Wijngaarden
>>>>>>
>>>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>>>>>
>>>>> Retiring epel7's puppet may be the preferred option. It is
allowed
>>>>> [0], but if you go this route please mention it on the epel-devel
list
>>>>> (and perhaps epel-announce) first.
>>>>
>>>> I should have realized this, will bring it up there.
>>>>
>>>>> Alternatively, have you considered doing an incompatible update [1]
to
>>>>> version 5? It may already be EOL, but surely that's a better
option
>>>>> than the current version 3 or removing it entirely.
>>>>
>>>> The Ruby version in EL7 is simply too old. In theory you could write a
>>>> ton of patches to make it compatible again, but the Puppet modules users
>>>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
>>>> itself is already EOL (for more than a year), but packaging Puppet 6 vs
>>>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you
need
>>>> a newer Ruby. After that it's all minor differences.
>>>>
>>>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>>>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>>>
>>> Bundle a newer Ruby?
>>
>> RHEL 7 has published "software collection library" versions of ruby,
>> titled "rh-ruby25".
>>
>> As somebody who's backported bulky software for RHEL based operating
>> systems, like Samba and current ansible and airflow and yes, years
>> ago, puppet, I don't recommend installing your own ruby. Resolving the
>> dependencies gets painful, fast.
>
> In that case, I would be fine with saying, “if you need to run Puppet
> on RHEL 7, do so in a container or VM based on a newer RHEL”.
>
Puppet is not very useful in a container. It's a systems management
tool, so it's designed to manage the computer itself.
Good catch, sorry. I had not thought of that.
If Puppet supports managing chroots, one could use a privileged
container that has the host’s root directory bind-mounted into it,
and uses host namespaces except for mount. Still, your point stands.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
728
days inactive
731
days old
13 comments
6 participants
participants (6)
-
Breno Brand Fernandes -
Carl George -
Demi Marie Obenour -
Ewoud Kohl van Wijngaarden -
Neal Gompa -
Nico Kadel-Garcia