On Mon, Nov 22, 2021 at 10:12 AM Carl George <carl(a)redhat.com> wrote:
On Mon, Nov 22, 2021 at 8:37 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
>
> On 22/11/2021 15:00, Pavel Raiskup wrote:
> > - builds will require a valid Red Hat subscription (the no-cost variant is
> > OK as well, though [2])
>
> I'm going to retire all my EPEL8 packages as I can't build/test them in
> mock without any subscriptions.
>
> --
> Sincerely,
> Vitaly Zaitsev (vitaly(a)easycoding.org)
> _______________________________________________
> 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
This has always been allowed. EPEL packagers are not required to
maintain their packages for the entire corresponding RHEL lifecycle.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
I will point out that it's trivial to avoid dealing with a
subscription by doing koji scratch builds, or by using the existing
oraclelinux-epel-8-x86_64 mock chroot, or by submitting equivalent
{clone}-epel-8-{arch} chroots to mock-core-configs for your preferred
clone. Mass retiring all of your epel8 packages seems like an
overreaction to me, but it is your choice. If you do decide to go
that route I hope you're welcoming to other maintainers that offer to
co-maintainer your packages to be responsible for the epel8 branch
going forward. Ideally you would also send an email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
Note that I've submitted a PR to switch from CentOS Linux to
AlmaLinux[1] for similar reasons (my workflow would be totally broken
if I had to deal with the foibles of subscription-manager for building
packages).
[1]:
https://github.com/rpm-software-management/mock/pull/803
--
真実はいつも一つ!/ Always, there's only one truth!