Lasso, as provided in EL7, EL8 and EL9, doesn't have a perl-lasso sub-package, which provides the perl bindings. It is not built for EL7, and is built but not shipped for both EL8 and EL9.
Quite some time ago, I have filed a ticket requesting that the perl and python bindings be shipped in EL8 and EL9 [1]. python was just a guess, but it turned out to be correct. It was granted for python, as epsilon as a need for it, but was not for perl. I have since re-opened the ticket, as the software I need the perl bindings for is now available in Fedora, which does have the perl sub-package and thus has SAML support, and also in EPEL, where SAML support is indeed missing [2].
I have prepared a perl-lasso-epel spec file to add missing perl bindings support to EL releases and as this is the first time I go this route, although the EPEL guidelines states this is a review request exception [3], I would like the package to be looked at by people with more experience on the matter.

The SRPM I linked above is for EL7, but SRPMs for EL8 and EL9 are available too:
https://www.bachelot.org/fedora/SRPMS/perl-lasso-2.6.0-1.el8.src.rpm
https://www.bachelot.org/fedora/SRPMS/perl-lasso-2.7.0-1.el9.src.rpm

The only difference is the version which indeed varies from one release to another

Thanks,
Xavier

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2041941
[2] https://src.fedoraproject.org/rpms/lemonldap-ng
[3] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/

Hi Xavier, I can take a look and help.

The spec file and SRPM names for these are incorrect.  The spec file should be named lasso-epel and the Name tag should be lasso-epel.  From this setup, you can create a perl-lasso subpackage, or rather delete all the sections of the existing spec file that aren't relevant to the perl-lasso subpackage.  Notably this means that you won't have a %files section, using just %files -n perl-lasso to ship the files you need.

I think the best first step would be to get the dist-git repo created, request the desired epel* branches, import the relevant CentOS SRPMs, and then make the necessary changes as pull requests for review.  There is a guide for most of these steps in the EPEL documentation.

https://docs.fedoraproject.org/en-US/epel/epel-packaging-examples/#_missing_but_built_examples

After the step of editing the spec file, instead of committing directly you can propose those changes as a pull request to your own package.  This will make it easier to review the changes and ensure things are set up correctly.

If you would like to chat about this interactively, myself and others are happy to help in the EPEL Matrix channel.

https://matrix.to/#/#epel:fedoraproject.org

Hi Carl,

Thanks for the answer.
I have renamed and modified the specfile according to your guidance.
The modified specfile is built on top of lasso from Rawhide branch plus a spec cleanup PR that I have submitted.
(https://src.fedoraproject.org/rpms/lasso/pull-request/14)
I chose this way as I have already submitted a couple PRs to lasso that have been accepted, most notably in order to fix and improve perl bindings subpackage creation.
I understand this is not exactly the way it should be done, as indeed EL7, EL8 and EL9 spec files have quite some differences, but I'd prefer to make use of these improvements, if at all possible.
Nevertheless, with this specfile, I am able to build for all of the EL branches with just a version number change, so I believe this might be an acceptable compromise and a low maintenance burden.

Here are the updated specfile and SRPMs: 

Spec URL: https://www.bachelot.org/fedora/SPECS/lasso-epel.spec
EL7 SRPM URL: https://www.bachelot.org/fedora/SRPMS/lasso-epel-2.5.1-1.el7.src.rpm
EL8 SRPM URL: https://www.bachelot.org/fedora/SRPMS/lasso-epel-2.6.0-1.el8.src.rpm
EL9 SRPM URL: https://www.bachelot.org/fedora/SRPMS/lasso-epel-2.7.0-1.el9.src.rpm

Regards,
Xavier

I think instead of creating separate package for just epel, I think request should be made to move perl-lasso from buildroot into CRB repository, at least for RHEL9. I would consider that cleaner way than creating epel-only package.

I have found existing issue, which seems it has been exported:
- https://issues.redhat.com/browse/SSSD-3406
- https://issues.redhat.com/browse/RHELPLAN-42156

It seems to be requested only on RHEL8 already, it should be requested also for RHEL9. But that requested only lasso-devel. I think similar request should be made for perl-lasso (any any alternative bindings too).

Filled a new bug https://issues.redhat.com/browse/RHELPLAN-168501, I think it were left in internal buildroot as an oversight when moved devel subpackage into CRB.

It would take a lot of time, but I think is more preferred solution than continuing this review. A package, which conflicts with RHEL packages, cannot be included in EPEL. It would make sense to include only epel7 version of this package, because that won't be exported this way.

Hi Petr,

Thanks for filing the Jira tickets (although I don't have access to them, but I guess this is expected).
Indeed, my solution of choice to the issue would be to get the missing sub-package with the perl bindings into CRB. I already tried, as noted in comment#1, but that did not work.
Just to make sure, I do need both perl-lasso for EL8 and for EL9.

IMHO, pursuing the review is still worthwhile, as no one can tell how many time it will take for perl-lasso to make it to CRB.
Also, lasso-epel would not conflict with any published RHEL package, as it is just providing perl-lasso which is currently not in any repo.
And anyway, perl-lasso for EL7 doesn't exist at all.

Regards,
Xavier

Hi Carl, Petr, 

Any update here ?
Petr, as I don't have access to the Jira tickets, I don't know if anything happened on the RHEL side of things ?
Carl, are the changes I made to the specfile correct ? I have a local change added to the previous spec that defines version according to the elX macro, which would allow to keep all the epel branches for lasso-epel in sync.

```
%{?el7:%global lasso_version 2.5.1}
%{?el8:%global lasso_version 2.6.0}
%{?el9:%global lasso_version 2.7.0}

Version: %{lasso_version}
```

Regards,
Xavier

> I think instead of creating separate package for just epel, I think request should be made to move perl-lasso from buildroot into CRB repository, at least for RHEL9. I would consider that cleaner way than creating epel-only package.

I agree, that would indeed be a more optimal solution long term.  Encouraging the lasso-epel route was based solely on this being declined in bug 2041941.  If you are able to influence that and get the perl-lasso subpackage shipped in CRB, I would certainly prefer that path.  In the mean time, we can proceed with lasso-epel, and just retire it when/if the CRB request gets completed.

> It would take a lot of time, but I think is more preferred solution than continuing this review.

Not too much time really.  Once the RHEL maintainer for lasso agrees to shipping perl-lasso in CRB, they can increment the release of the package with no other changes and complete a CentOS Stream build.  That build could be shipped in the next CentOS Stream compose, which usually happens weekly.  That would get community members a public RPM artifact that they could start to use.  EPEL maintainers can leverage it via EPEL Next.  It would take a few more months to show up in RHEL 9.4 CRB to be used by the main EPEL repo.

> A package, which conflicts with RHEL packages, cannot be included in EPEL.

That is the purpose of the -epel suffix for this package.  It allows the package to exist in Fedora dist-git without runing afoul of the logic that blocks dist-git repo names that match RHEL SRPM names.  The built packages would not conflict as long as lasso-epel doesn't ship any subpackages that are shipped in RHEL.  EPEL packages are allowed to conflict with packages that are only in the RHEL buildroot and not shipped in the public repos.  This is standard practice endorsed by the EPEL Steering Committee.

https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
https://docs.fedoraproject.org/en-US/epel/epel-packaging-examples/
https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy

> It would make sense to include only epel7 version of this package, because that won't be exported this way.

Xavier only mentioned needing this for EL8 and EL9, so maybe we can just skip epel7, considering how close it is to EOL anyways.

> Any update here ?
> Petr, as I don't have access to the Jira tickets, I don't know if anything happened on the RHEL side of things ?
> Carl, are the changes I made to the specfile correct ?

No update yet on getting perl-lasso shipped in CRB.  The good news is we don't have to block this review on that.  We can complete lasso-epel, get perl-lasso shipped in EPEL, and then when/if the CRB request happens retire lasso-epel.

> I have a local change added to the previous spec that defines version according to the elX macro, which would allow to keep all the epel branches for lasso-epel in sync.

After having maintained a few *-epel packages, I would discourage you from going this route.  For normal EPEL packages I agree that it is nice to keep dist-git branches in sync, but in this case it makes things more complicated than they need to be.  From a maintenance perspective the best choice is to keep the lasso-epel spec file as close to the relevant sections of the RHEL lasso spec file as possible, and letting the git branches diverge appropriately.  This will also help ensure a smooth transition from EPEL's perl-lasso to RHEL's perl-lasso in the future.

I went ahead and requested the lasso-epel dist-git repo.  Since it's excluded from the normal review process, I used the exception flag, which will require manual RelEng approval.  Once created I'll add you as a maintainer, import the relevant CentOS RPMs to populate the epel8 and epel9 branches, and then we can make the minmal changes to cause the package to only ship the perl-lasso subpackages.

https://pagure.io/releng/fedora-scm-requests/issue/58967

FEDORA-EPEL-2023-b80695f129 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b80695f129

FEDORA-EPEL-2023-9d94e57b58 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9d94e57b58

After importing the CentOS RPMs, I realized how straightforward this one would be, so I proceeded to complete the minimal changes needed.  I've added you Xavier as a co-maintainer.

https://src.fedoraproject.org/rpms/lasso-epel

Once those bodhi update move to stable, perl-lasso will be available in EPEL 8 and EPEL 9, basically identical to the unshipped RHEL packages.  We should limit the changes to just syncing up with changes made to the CentOS/RHEL spec files, to ensure that we don't make an change that gets rolled back when upgrading to a future proper RHEL perl-lasso package.  Speaking of that future upgrade, if we do need to make changes, we should ensure the release stays lower than what the next RHEL package will most likely be.  An easy way to do that will be to follow the Fedora policy for older branch only release bumps.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rebuilds_in_older_branches_using_minorbump

So for us that will look like:

2.6.0-13.el8   (current RHEL 8 lasso and EPEL 8 perl-lasso)
2.6.0-13.el8.1 (future EPEL 8 perl-lasso)
2.6.0-13.el8.2 (future EPEL 8 perl-lasso)
2.6.0-14.el8   (future RHEL 8 lasso and perl-lasso)

2.7.0-11.el9   (current RHEL 9 lasso and EPEL 9 perl-lasso)
2.7.0-11.el9.1 (future EPEL 9 perl-lasso)
2.7.0-11.el9.2 (future EPEL 9 perl-lasso)
2.7.0-12.el9   (future RHEL 9 lasso and perl-lasso)

Let me know if you have any questions about how this intended to work.

Thanks Carl :-)

I have created a PR for the epel8 branch, could you please take a look, especially the release bump ?
https://src.fedoraproject.org/rpms/lasso-epel/pull-request/1

Also, I have requested an epel7 branch, but I wasn't able to find the original SRPM, which seems to be missing from https://downloads.redhat.com/redhat/linux/enterprise/7Server/en/os/SRPMS/
I used the CentOS SRPM from https://vault.centos.org/7.9.2009/updates/Source/SPackages/lasso-2.5.1-8.el7_9.src.rpm.
I wanted to create a PR for this too, but mistakenly pushed to origin instead of my fork :-(
Hopefully, I got it right, but it's not been built yet (except locally, indeed).
https://src.fedoraproject.org/rpms/lasso-epel/commits/epel7

> I have created a PR for the epel8 branch, could you please take a look, especially the release bump ?

As noted in the PR, it looks good to me.

> I used the CentOS SRPM from https://vault.centos.org/7.9.2009/updates/Source/SPackages/lasso-2.5.1-8.el7_9.src.rpm.

Using the CentOS SRPM is indeed the correct way to go about this.

> I wanted to create a PR for this too, but mistakenly pushed to origin instead of my fork :-(
> Hopefully, I got it right, but it's not been built yet (except locally, indeed).

No worries, your epel7 branch work looks good to me as well.

Heads up Petr, Xavier filed an issue and corresponding MR for a problem in the perl-lasso subpackage in RHEL 8.

https://issues.redhat.com/browse/RHEL-20218
https://gitlab.com/redhat/centos-stream/rpms/lasso/-/merge_requests/16

Hopefully that can be merged and included when adding the package to CRB.

FEDORA-EPEL-2023-b80695f129 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b80695f129

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2023-b80695f129 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.