On Mon, Sep 20, 2021 at 10:48 AM Vít Ondruch <vondruch@xxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
