On Fri, Sep 17, 2021 at 12:06 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>
>
> Dne 16. 09. 21 v 14:19 Kalev Lember napsal(a):
>
> On Thu, Sep 16, 2021 at 2:14 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>>
>> On Thu, Sep 16, 2021 at 1:09 PM Fedora Rawhide Report
>> <rawhide@xxxxxxxxxxxxxxxxx> wrote:
>> > ===== ADDED PACKAGES =====
>> > Package: atkmm2.36-2.36.1-1.fc36
>> > Summary: C++ interface for the ATK library
>> > RPMs: atkmm2.36 atkmm2.36-devel atkmm2.36-doc
>> > Size: 1.35 MiB
>>
>> (...)
>>
>> > Package: glibmm2.68-2.68.1-1.fc36
>> > Summary: C++ interface for the GLib library
>> > RPMs: glibmm2.68 glibmm2.68-devel glibmm2.68-doc
>> > Size: 12.65 MiB
>> >
>> > Package: gtkmm4.0-4.4.0-1.fc36
>> > Summary: C++ interface for the GTK+ library
>> > RPMs: gtkmm4.0 gtkmm4.0-devel gtkmm4.0-doc
>> > Size: 17.64 MiB
>> >
>> > Package: pangomm2.48-2.48.1-1.fc36
>> > Summary: C++ interface for Pango
>> > RPMs: pangomm2.48 pangomm2.48-devel pangomm2.48-doc
>> > Size: 1.26 MiB
>>
>> Is there a reason why these compat packages are done "the wrong way round"?
>> They were requested with exceptions to the review process, but that
>> exception only applies to requesting versioned compat packages for the
>> *old* version, not the other way round ...
>
>
> Sure, there's a good reason! I wanted to keep the same pattern as gtk has, so that there's gtk3 and matching gtkmm3.0, and gtk4 and matching gtkmm4.0.
>
> They are all long-lived parallel installable packages and most stuff is going to be using the "old" gtkmm3.0 still for a number of years to come.
>
> Doing it this way also makes it much easier to add the new packages to F34 where I don't want to be undertaking large package renaming.
>
>
> 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
- 💣 this doesn't work since those two packages conflict (usually on
unversioned libfoo.so)
And, as mentioned by kevin, even if the -devel packages were
parallel-installable:
- much more downloads of packages for unrelated packaging changes (for
example, non-compat package is updated, compat package doesn't change)
- doubled build times for unrelated changes (both non-compat and
compat package always both need to be built)
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
