Dne 18. 09. 21 v 10:18 Fabio Valentini napsal(a):
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
I might be missing something, but this sounds as asking for troubles.
- 💣 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)
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.
- 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? ;)
Vít
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
_______________________________________________
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
