Please note that qpdf is in the list of Removed Packages for Red Hat Enterprise Linux 9

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_changes-to-packages_considerations-in-adopting-rhel-9#removed-packages_assembly_changes-to-packages

qpdf-libs is included as an internal dependency.

Ah, OK, that sort of explains it. I see that qpdf-libs is needed by cups-filters. It seems super weird
to me that you'd maintain the source rpm, but then not make the main package available. Why is that
a helpful thing to do? Shouldn't the main qpdf rpm at least be in EPEL?

Thanks,
Andy

Hi Andrew,

the package was stopped being shipped in public RHEL/CentOS Stream repos because it was found out during RHEL minimization process there were no dependencies which required qpdf during runtime, so qpdf is currently only in buildroot repository, because there was a package which uses it during build.

Currently I'm not aware that it's possible to have only one rpm from srpm in EPEL without introducing a separate component with stripped source tarball... Josh, do you know whether it is possible to ship one RPM in EPEL?

Otherwise, in case you need qpdf in RHEL and you have an active subscription, it would be great if you filed a ticket at https://access.redhat.com and I can prioritize the issue.

(In reply to Zdenek Dohnal from comment #3)
> Hi Andrew,
> 
> the package was stopped being shipped in public RHEL/CentOS Stream repos
> because it was found out during RHEL minimization process there were no
> dependencies which required qpdf during runtime, so qpdf is currently only
> in buildroot repository, because there was a package which uses it during
> build.
> 
> Currently I'm not aware that it's possible to have only one rpm from srpm in
> EPEL without introducing a separate component with stripped source
> tarball... Josh, do you know whether it is possible to ship one RPM in EPEL?

It is not possible to ship binary RPMs from RHEL in EPEL repositories.

Hi, OK, but this is kind of an ugly situation. For users who want or need qpdf, there's now no reasonable
way to get it. I had to download the qpdf source rpm from RHEL and then rebuild it to get the qpdf main rpm
that's compatible with the qpdf-libs in RHEL. That's really weird. I can understand the desire
to minimize RHEL, but if you need qpdf-libs in RHEL, you should just include qpdf as well. That's
my two cents. Thanks for listening.

I understand your position on the matter, however adding qpdf into AppStream would add additional responsibilities to support for the package, which I would not want to do without a request from the proper support channels. And since qpdf is needed for building a package in RHEL, I cannot strip it from RHEL and release it as a separate package in EPEL.

I will consult on our discussions how we can tackle such packages - whether we can open some parts of buildroot as unsupported or by any other means - but for now I will close the bug. Feel free to reopen if there is a request via the official support channel.

In the meantime I will provide steps how to compile your own qpdf RPM, in case it is needed:

```
$ pwd
/home/<user>
$ sudo dnf -y install rpm-build
$ mkdir qpdf && cd qpdf
$ dnf download --source qpdf
$ rpm2cpio <downloaded_srpm> | cpio -idmv
$ sudo dnf -y builddep *.spec
$ rpmbuild --rebuild <downloaded_srpm>
$ sudo dnf -y install /home/<user>/rpmbuild/RPMS/<qpdf_rpm>

```

Thanks. I am well aware of how to build the package. And FYI, there's no need to unpack
it with rpm2cpio to run "dnf builddep", since that command can take a source rpm as
an argument, in addition to a spec file. From "man dnf builddep":

SYNOPSIS
       dnf builddep <package>...

ARGUMENTS
       <package>
              Either path to .src.rpm, .nosrc.rpm or .spec file or  package  available  in  a
              repository.

I really think you guys need a better way to deal with situations like this. The present solution
is very clunky and unsatisfying.

Regards, 
Andy

(In reply to Andrew Schorr from comment #7)
> Thanks. I am well aware of how to build the package.

I'm sorry, my comment didn't seem to be clear - I'm aware that you are able to build the package, the steps were for others who need qpdf, see this bugzilla and they're not experienced to do the RPM build.

The intent was to help others and spare their time with reading RPM man pages/manuals/how-to's on the internet.

> And FYI, there's no
> need to unpack
> it with rpm2cpio to run "dnf builddep", since that command can take a source
> rpm as
> an argument, in addition to a spec file. From "man dnf builddep":
> 
> SYNOPSIS
>        dnf builddep <package>...
> 
> ARGUMENTS
>        <package>
>               Either path to .src.rpm, .nosrc.rpm or .spec file or  package 
> available  in  a
>               repository.

Aha, thanks! I don't do building from srpm that often (I use wrapper tools above them) and I always use installing build deps from SPEC file, so good to know this, thanks again!

So the updated steps for people who want qpdf and they're not experienced in RPM:

```
$ pwd
/home/<user>
$ sudo dnf -y install rpm-build
$ mkdir qpdf && cd qpdf
$ dnf download --source qpdf
$ sudo dnf -y builddep <downloaded_srpm>
$ rpmbuild --rebuild <downloaded_srpm>
$ sudo dnf -y install /home/<user>/rpmbuild/RPMS/<qpdf_rpm>

```

> 
> I really think you guys need a better way to deal with situations like this.
> The present solution
> is very clunky and unsatisfying.

According to the email conversation, there is a possibility to move the rpm to CRB repository - I'm checking what is needed to request that. In case this bug would fit in, I will reopen and move this through.

Zdenek

Ok, so I have everything I need, I'm reopening the issue.

I propose moving qpdf RPM from buildroot into public CRB repository for the following reasons:

- qpdf is requested by CentOS Stream user and the RPM was in previous RHELs and CentOS, so it would be great if the RPM was available publicly as unsupported to keep the functionality in RHEL/CentOS Stream

- no new packages are introduced into public RHEL/CentOS Stream, because the RPM was in buildroot already, and none of its deps has to move with it to CRB, so there is no impact on other teams

- packages in CRB are unsupported, so there is no requirement for migration support between RHELs, no compatibility assurance and no additional tests have to implemented

- the RHEL package which requires qpdf does it only during build time and the package is in AppStream, so no change for it either


Ping @Joe Orton, @Petr Sklenar and @Petr Dancak for review and acks as PO and QE.

Ack as PO to add this to CRB.

Filed MR

https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/253

We are currently waiting for MR from comment #13 to be merged - then I can create a new build which will get qpdf into CRB.

Committed as https://gitlab.com/redhat/centos-stream/rpms/qpdf/-/commit/0f45be3405469985613976d34a7f3962dbfd6c12?merge_request_iid=4 .

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (qpdf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8200