On Mon, Sep 20, 2021 at 10:48 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>> Shouldn't we rethink how we provide such packages? I am thinking about
something like providing the compat packages as a subpackages of the original package?
> The problem with this scheme is that this breaks down completely as
> soon as there's two such packages that depend on one another (as in
> this case with glibmm and gtkmm), because -devel packages of
> non-compat and compat versions of the library conflict:
>
> - library foo needs to be packaged in version x and y
> - library bar needs to be packaged in version x and y
> - libbar-x requires libfoo-x, libbar-y requires libfoo-y
> - libbar source package produces libbar{,-devel} and libbarx{,-devel}
> - libbar needs to BuildRequire libfoox-devel and libfoo-devel
(snip)
I might be missing something, but this sounds as asking for troubles.
Yeah, it looks like you "missed" the obvious last point in this
argument, i.e. the one with the B💣MB marker next to it:
> - 💣 this doesn't work since those two packages conflict
(usually on
> unversioned libfoo.so)
(snip)
Does there need to be change in subpackage? Does Koji check
subpackages
NVRs? My bet is that it doesn't but I might be wrong. And there truth is
that there would not be clear which package goes into compose.
As far as I know, while you can set "Version" tag for each subpackage
independently, you cannot do the same for Release, and it is inherited
from the main package by all subpackages. So by definition, all
subpackages' NVRs will change with every update.
> - doubled build times for unrelated changes (both non-compat
and
> compat package always both need to be built)
Double motivation to get rid of compat packages? ;)
Can Red Hat hire a few dozen people to always port all the world's
programs to the latest library versions? That would be great!
Fabio