That is expected. The Name field is required to match the spec file name, which in turn must match the distgit repo name. When you requested the credcheck distgit repo, automation added credcheck to the allowed package list for f43 tag. When you requested the epel8 branch on that repo, automation added it to the allowed package list for the epel8 tag.

carl ~ 
❯ koji list-pkgs --package credcheck
Package                 Tag                     Extra Arches     Owner          
----------------------- ----------------------- ---------------- ---------------
credcheck               epel8                                    psloboda       
credcheck               f43                                      psloboda       

The postgresql16-credcheck package has never been added to any tags.

carl ~ 
❯ koji list-pkgs --package postgresql16-credcheck
2025-05-16 11:58:39,719 [ERROR] koji: GenericError: No such entry in table package: postgresql16-credcheck

What is the logic behind trying to use a different name for EPEL 8? There are ways to use that name if it truly makes sense, but I'd like to understand the reasoning first.

Hi,

the reason is we are expecting to be adding the plugin into epel8 for other
postgresql versions and the package works only with the version of
postgresql it was built with. Therefore the name change is to differentiate
between the postgresql versions the package was built with. This isn't
necessary with fedora as the package is available only for the distribution
default version of postgresql.

Regards,

Sloboda Pavol.

On Fri, May 16, 2025 at 7:03=E2=80=AFPM Carl George pagure@pagure.io wrot=
e:

carlwgeorge added a new comment to an issue you are following:
` That is expected. [TheName` field is required to match the spec file
name](
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_nam=
ing),
which in turn must match the distgit repo name. When you requested the
credcheck distgit repo, automation added credcheck to the allowed package
list for f43 tag. When you requested the epel8 branch on that repo,
automation added it to the allowed package list for the epel8 tag.

```
carl ~
=E2=9D=AF koji list-pkgs --package credcheck
Package Tag Extra Arches Owner

----------------------- ----------------------- ----------------

credcheck epel8 psloboda

credcheck f43 psloboda

```

The postgresql16-credcheck package has never been added to any tags.

carl ~ =E2=9D=AF koji list-pkgs --package postgresql16-credcheck 2025-05-16 11:58:39,719 [ERROR] koji: GenericError: No such entry in tabl= e package: postgresql16-credcheck

What is the logic behind trying to use a different name for EPEL 8? Ther=
e
are ways to use that name if it truly makes sense, but I'd like to
understand the reasoning first.

``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/12738

Why not build credcheck against the default postgresql (what you get when you "install postgresql") and then have compat packages (or even postgresqlNN-credcheck packages) for the other versions?

FWIW, I am pretty sure there is only one postgresql version available to build against in epel8.

epel8 'flattens' modules, only taking default ones and puts them all in a buildroot. There's no way to enable other non default module streams.

@mschorm

Why not build credcheck against the default postgresql (what you get when you "install postgresql") and then have compat packages (or even postgresqlNN-credcheck packages) for the other versions?

I wanted to get around the overhead of having to manage multiple repos when there is only one version for rawhide and one version for epel8 so far. I know I will have to do it eventually but I wanted to see if there are other options before doing that.

Hi, @james @kevin
yes, the situation is complicated.

The main goal is to add credcheck for single specific non-default version of postgresql (v16).

Why not build credcheck ... default ... and then have compat packages ... for the other versions?

And we also want to avoid building and supporting other versions, as there is no request for them and we must take our capacity into the account.

Why not build credcheck ... default ... and then have compat packages ... for the other versions?

Furthermore the plugin must be built against the target server version to work with it.

We chose to build a small part of the PG server inside of the credcheck to build against, and then only ship the credcheck plugin.
Ugly, yet the only sane workaround for building "against" (or rather "for") other module versions.

If we would want to build credcheck against more versions, we would need to make it even more complicated, as we would need to build the PG server for each module stream we would want to target. And then build credcheck against each.

We neither want nor have capacity to maintain this matrix.

Can you just add coditionals to the credcheck spec, to only on epel8 produce only a single binary package called 'postgresql16-credcheck' and on fedora/other places build whatever you do now?

That way 'credcheck' is still the source package, but it makes the binary package you wish out of it?

I have resolved this by keeping the Name of the package credcheck and renaming the output rpms by creating a %package inside the specfile named postgresql16-credcheck and renaming the -selinux subpackage to postgresql16-credcheck-selinux. This produces a source rpm named credcheck but all the correctly named output rpms.