On Tue, Aug 23, 2022 at 11:27:55AM -0400, Paul Wouters wrote:
Thanks for the link. Sadly, the justification would be "because
upstream
hardcoded this an errors on any other version", which in itself is
pretty weak. And since it includes boost, which can't easilly be
upgraded between fedora releases, all the older stuff lingers forever.
There is a little more to it: percona-xtrabackup also comes with
mysql (because it is basically running a copy of it's own mysql/innodb
to do it's job - just like the other comparable versions around). And
this mysql is what is "bound" to that boost version. xtrabackup just
inherits this bundling.
If you look at the percona-xtrabackup versioning you'll see that the
current upstream release is:
* percona-xtrabackup-8.0.29-22
and that refers to it's bundling of mysql 8.0.29
>Non-responsive maintainer policy [2]. This package has CVE bugs
>open [3],
There was _one_ CVE bug and that was for the old version of xtrabackup
that is not shipped for fedora. I have just closed that bug.
The other CVEs are for EPEL builds - while I am in theory interested in
fixing epel as well I won't touch it until the fedora branch is in a
better state.
Miro started the non-responsive maintainer process and woke up the
maintainer, but they themselves are also thinking it might be better
to kick it out of fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=1989019
Yes - the build process is cumbersome and it is a bad fit for fedora on
that alone. Yet for me it still scratches an itch and being able to do a
'dnf install percona-xtrabackup' is still useful.
--
sven