Richard Hughes wrote:
The problem is it simply does not work on anything nontrivial that
needs an updated library dep of something already in Fedora. On your
stable system running F25, can you try installing a few new versions
of upstream-active applications in F27 that requires the new QT or
GTK? Before you know it your super-stable production system is a huge
mix of incompatible packages,
Qt is normally upgraded in stable releases. Qt 5.9 is being prepared for F25
and F26. The upgrades mostly just work (Qt is fully backwards-compatible),
only the packages using private APIs (clearly tagged as such) need to be
rebuilt (the rebuilds are included with the updates upgrading Qt).
In addition, Qt applications often do not require the very latest Qt. E.g.,
the latest stable QupZilla still builds against Qt 5.7. Many upstream
projects even still support Qt 5.6.
which is unrecoverable. Downgrades are not supported officially, and
they're simply not something that is tested. If it works, it's more by
accident than design.
Your PackageKit does not support downgrades, but DNF does.
Flatpak lets me have multiple versions of apps installed, depending
on
specific versions of base libraries. We can actually test an
application always works using a known set of libraries, rather than
the application exploding because it's not doing runtime checks for
subtle changes in library behaviour.
This comes at a huge cost in space for duplicated libraries, a price that I
am not willing to pay.
> This is also trivial to offer in a UI.
I think you and I disagree on what trivial constitutes.
A Copr enabler GUI is very simple: just bring up a dialog box with a
checkbox list of Coprs (the checkbox enables or disables the Copr) and an
Apply button that does a distro-sync.
Until you're the person that's explaining to someone why
their system
is HOSED (hint: that's usually me) because they rebooted during a live
update, please don't call this a non-issue. Moving to offline updates
reduced the number of people filing bugs about systems being broken by
about two orders of magnitude. "But it always worked fine for me"
doesn't scale to tens of millions of users.
Rebooting during an update is a completely unrelated issue from the one that
was described. It will also break things if you do it during an offline
update.
And besides, systemd will not even allow you to shutdown or reboot during a
PackageKit update. (I accidentally tried to shutdown my notebook before my
plasma-pk-updates update was 100% complete lately, it just refused to shut
down and completed the update instead.) If you just cut the power, then you
deserve what you get.
Packages are a great way to build a system (either ostree or
flatpak,
or both), but I think the last 15 years of experience shows us it's
not a great way to manage a system.
Yet I have been using packages to manage my system just fine during those 15
years, it works much better than the alternatives.
Nobody is taking away packages. If you want to use packages, fine,
please
don't prevent us doing new, better things.
Really? Then why is Owen talking about allowing or even requiring GUI
applications to be Flatpak only? Don't take my RPMs away!
Kevin Kofler