Kevin Kofler kirjoitti 16.07.2017 klo 15:11:
Matthew Miller wrote:
> AND the ability to roll back, to choose beta or stable streams, etc.
> For example, the Google Play app store, you can check a box to opt in
> to beta versions of an app you're interested in following the bleeding
> edge of. It'd be awesome to do that in Fedora. We *could* do that with
> traditional packaging, but in practice doing it well seems like at
> least as much work as the flatpak bundle approach — and we still
> wouldn't get the update advantage.
su - (or sudo -i)
dnf copr enable myapp-beta
Opt back out and roll back:
su - (or sudo -i)
dnf copr disable myapp-beta
Where's the problem? This is also trivial to offer in a UI.
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?
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.
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