Re: Offering plasma-pk-updates as an alternative to Discover

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2021-05-09 at 10:38 -0400, Neal Gompa wrote:
> On Sun, May 9, 2021 at 10:11 AM Sérgio Basto <sergio@xxxxxxxxxx>
> wrote:
> > 
> > On Sun, 2021-05-09 at 09:28 -0400, Neal Gompa wrote:
> > > On Sun, May 9, 2021 at 9:19 AM Patrick Boutilier <
> > > boutilpj@xxxxxxxxxxx> wrote:
> > > > 
> > > > 
> > > > 
> > > > On 5/9/21 10:10 AM, Neal Gompa wrote:
> > > > > On Sun, May 9, 2021 at 8:19 AM Patrick Boutilier <
> > > > > boutilpj@xxxxxxxxxxx> wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 5/9/21 9:08 AM, Patrick Boutilier wrote:
> > > > > > > On 5/6/21 4:06 PM, Tomáš Trnka wrote:
> > > > > > > > Hello everyone,
> > > > > > > > 
> > > > > > > > After updating to F34, I was unpleasantly surprised by
> > > > > > > > the
> > > > > > > > new Plasma
> > > > > > > > update
> > > > > > > > notifier (plasma-discover-notifier). Even though the
> > > > > > > > previous
> > > > > > > > plasma-pk-updates
> > > > > > > > thing had its quirks and Apper also wasn't the most
> > > > > > > > featureful of package
> > > > > > > > managers, I still ran into a handful of issues with
> > > > > > > > Discover
> > > > > > > > that make it
> > > > > > > > pretty much useless for me:
> > > > > > > > 
> > > > > > > > – There seems to be no way to select which updates to
> > > > > > > > install. All I
> > > > > > > > can see
> > > > > > > > is a list of available updates with a button to install
> > > > > > > > all
> > > > > > > > of them,
> > > > > > > > but no
> > > > > > > > way to pick and choose a subset. (Yes, I could use
> > > > > > > > commandline DNF with a
> > > > > > > > whole bunch of "-x" arguments to get the job done, but
> > > > > > > > the
> > > > > > > > point of a
> > > > > > > > GUI is
> > > > > > > > to make things more user friendly, isn't it?)
> > > > > > > > – I can't seem to find the description of individual
> > > > > > > > package
> > > > > > > > updates
> > > > > > > > (the short
> > > > > > > > changelog that plasma-pk-updates shows when you click a
> > > > > > > > particular
> > > > > > > > package,
> > > > > > > > together with Bugzilla or Bodhi links). Again, getting
> > > > > > > > these
> > > > > > > > any other
> > > > > > > > way
> > > > > > > > than through the GUI updater is a real hassle.
> > > > > > > > – The tray notifier doesn't let me actually do anything
> > > > > > > > directly, I
> > > > > > > > have to
> > > > > > > > wait for it to open a full Discover window and spend a
> > > > > > > > long
> > > > > > > > while
> > > > > > > > loading the
> > > > > > > > updates, which is much more disruptive than the few
> > > > > > > > seconds
> > > > > > > > needed to
> > > > > > > > trigger
> > > > > > > > updating through plasma-pk-updates.
> > > > > > > > 
> > > > > > > 
> > > > > > > Even worse is that every single update requires a reboot.
> > > > > > > I
> > > > > > > just took a
> > > > > > > fully updated system and then downgraded vlc. Updated
> > > > > > > with
> > > > > > > Discover and
> > > > > > > even though it only had to update vlc-core-3.0.13-
> > > > > > > 1.fc34.x86_64
> > > > > > > and
> > > > > > > vlc-3.0.13-1.fc34.x86_64 it still required a reboot.
> > > > > > > 
> > > > > > 
> > > > > > Looks like this will be an option in 5.22 .
> > > > > > https://invent.kde.org/plasma/discover/-/merge_requests/111
> > > > > > 
> > > > > > Although I am not sure how doing an online vlc update will
> > > > > > cause
> > > > > > an
> > > > > > "unstable system". It wouldn't be so bad if there were not
> > > > > > almost
> > > > > > daily
> > > > > > updates available.
> > > > > > 
> > > > > 
> > > > > We don't have a heuristic for differentiating what a "safe
> > > > > update"
> > > > > and
> > > > > an "unsafe update" would be. In the VLC case, it would be
> > > > > "safe" as
> > > > > long as the phonon-vlc backend was not used for KDE Plasma
> > > > > (we
> > > > > don't
> > > > > use it by default, but someone could swap it in from a third-
> > > > > party
> > > > > build).
> > > > > 
> > > > > It can get fairly complicated, and it's always been a bad
> > > > > idea to
> > > > > update the desktop software while it's running from within
> > > > > the
> > > > > terminal of the said desktop, because you can lead to a
> > > > > scenario
> > > > > where
> > > > > you've temporarily caused a broken state that would only be
> > > > > fixed
> > > > > by
> > > > > rebooting anyway. For the majority of users, offline updates
> > > > > for
> > > > > packages is the correct behavior.
> > > > > 
> > > > > That said, yes, Plasma 5.22 (coming in a month) will
> > > > > introduce a
> > > > > user-accessible option to turn it off.
> > > > > 
> > > > > 
> > > > 
> > > > Is there any way for the packages themselves to "request"
> > > > offline
> > > > updates? I agree that updating plasma, kf5-*, etc.. live is not
> > > > a
> > > > good
> > > > idea. But something like nano for instance shouldn't need to be
> > > > updated
> > > > offline.
> > > > 
> > > 
> > > It is possible, but basically none of the PackageKit backends
> > > tell
> > > PackageKit this information, so the frontends are working blindly
> > > to
> > > try to do the right thing. I'm trying to figure out if I can
> > > extend
> > > the DNF backend to start offering that information.
> > > 
> > > Since Fedora has updateinfo and we (Fedora KDE team) set the
> > > value
> > > correctly when we submit updates, it should be possible for me to
> > > plumb this through. It looks like I'll need to extend libdnf's
> > > API
> > > first to do it, so that's going to take some time.
> > 
> > Hello,
> > Sorry I will ask a complete off-topic question.
> > I had remove packageKit of my system because it didn’t work well
> > and
> > used a second database of rpms, today after reviewing the bugs
> > opened
> > about 10 years ago, I found this one [1] that took 5 years to close
> > but
> > they didn’t answer my question, the packagekit already uses the
> > same
> > base of dnf data?
> > As far I'm concerned I would be happy if we drop packagekit
> > dependencies.
> > 
> 
> It doesn't use a second RPM database. It uses the same one as DNF.
> Over the past couple of years, the PackageKit DNF backend has been
> reworked to respect more global settings and behaviors. There's still
> more work to do, but it's at least being worked on.
> 
> If you don't like PackageKit based stuff, you're free to use
> dnfdragora instead.

It is not about not liking the PackageKit, I felt that the packagekit
never worked well and nobody cares, for many years, so I give up on use
it (around 2015). I started not having notifications of updates and I
don't even dislike it, now I update when I remember to check it :D . 

Best regards, 
-- 
Sérgio M. B.
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-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/kde@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [KDE Users]     [Fedora General Discussion]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Triage]     [Coolkey]     [Yum Users]     [Yosemite Forum]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux