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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
