Joonas Sarajärvi wrote:
> What if upgrading to myapp-beta requires upgrading also e.g. to a major
> version of Qt (or any other widely used library that has some potential
> to either have regressions or even just be incompatible between
> versions) that is more recent than what my Fedora installation ships? If
> distro-sync proposes any upgrades beyond the one thing that the user
> really wants to upgrade, how will any non-technical user be able to tell
> if this will destabilise something else?
Fedora normally already offers the latest version of Qt in the stable
updates. (Qt 5.9.x updates for Fedora 25 and 26 are coming soon.) Qt is
fully backwards compatible, so upgrading it is normally not an issue. And
really MAJOR new versions of Qt, e.g. 4 vs. 5, are fully parallel-
installable.
And this is the model that should be followed for other libraries with the
same type of branching strategy as well. Just upgrade the system version.
Now, if the system version of a library is too old, the Copr can simply
offer a newer version. That (and also automatic updates, of course) is what
Copr is for, as opposed to just pointing to a single RPM. And of course,
disabling the Copr and doing a distro-sync will also revert those libraries.
> With flatpak and other comparable tools, the application can set up to
> use a more recent runtime while the existing applications are left
> untouched. Even for a user who gets all their software from Fedora, I'd
> expect it to be possible for a user of stable Fedora N to pick any of
> the application versions available in Fedora (N-1), (N+1) and rawhide.
I do not consider this a realistic expectation, at all.
> At least I have so far pretty much avoided all COPR use because I wish
> to spend time on something else than judging this. I have some
> applications installed through flatpak and there it is nice to know that
> the installations do not affect how the programs that I get from Fedora
> work.
And I would pick a Copr over a Flatpak any day. I used and use several Copr
repositories, they are much nicer than some unpackaged blob. And getting rid
of them later is fairly easy.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
