Stephen Gallagher wrote:
> You don't want to do that for libraries in general.
Well yes. But the thing is, I am not convinced that this is universally
agreed on, unfortunately.
What I really worry about is a scenario where, say, the KDE module includes
NetworkManager version x, and the GNOME module includes NetworkManager
version y (y≠x), making it impossible to install both desktops, or even just
applications from the foreign desktop that happen to be included in and/or
depend on that desktop's module.
> Rather, it makes more sense if you need to swap out a framework of tightly
> interdependent packages. (Node.js or Django would be reasonable examples
> here).
That still means that if there are 2 unrelated web apps based on a different
version of Node.js or of Django, those web apps cannot be installed on the
same web server, which is a quite unfortunate restriction.
Node.js and Django are really just (sets of) libraries, too!
> Another example that would make sense is... KDE. Instead of doing a
> mass-upgrade in the middle of a release, you could make the Plasma
> Workstation packages into a module with KDE release number as the stream.
> Then people could switch voluntarily to the next version if they want to
> do so mid-release or they can wait until an upgrade to the next release
> moves them over.
Given that "KDE" is actually Plasma Workspaces, KDE Applications, and KDE
Frameworks, which release on separate schedules (there have no longer been
monolithic "KDE" releases for several years now!), but where newer Plasma
and Applications often require newer Frameworks too, and given that there
are also third-party applications using the KDE Frameworks, modularizing the
KDE software stack is not as straightforward as you seem to think.
I think at least the KDE Frameworks will always need to be updated distro-
wide, i.e., ursinely. For one, they are libraries (see the discussion
above). And they maintain backwards compatibility, but of course not
forwards. In addition, upstream do not maintain separate bugfix branches of
KDE Frameworks, one is just expected to always upgrade to the latest monthly
release (and point releases are only made in the rare event an intermediate
release is needed). So one is normally always better off with the latest
version.
But the KDE Applications bundle also ships a handful libraries, which
typically do not maintain backwards compatibility (which is usually the
reason they are not in Frameworks), and on which some external applications
may depend, and there can also be external packages depending on the Plasma
Workspaces. Hence, there may be packages that need to be rebuilt together
with KDE Applications and/or Plasma Workspaces and would have to be added to
their modules (if we were to make them modules), too.
And finally, I am not convinced what value that would really bring us over
the existing solutions (Copr on one hand and official ursine updates on the
other hand, on a case by case basis).
> But if those were fixed, wouldn't it be *really convenient* to update the
> packages and then kick off a single build that would build for all
> active Fedora (and/or EPEL) releases?
I don't think this is ever going to work that easily. Building once on one
release and shipping for all is not going to work (that might be workable
for Rust code, but definitely not for C++ code), and building for all
releases separately at the same time means dealing with the errors specific
to different releases (and also with the release-independent errors) all at
the same time. This means that it will take longer to get new builds out for
Rawhide, because the maintainer will be stuck also fixing the errors on
Fedora n and even Fedora n-1 before being able to proceed with the Rawhide
build.
Kevin Kofler
_______________________________________________
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
