F27: how to disable packagekit to download updates

[Dario Lesca]

How to I can disable packagekid to download update?

I do not use these packages downloaded uselessly from packagekit into
/var/cache/PackageKit/*/*/updates/... because I run sometimes when I
want and can, after, reboot, "sudo dnf update".

Unfortunately this command (dnf) do not use the rpm files download from
PackageKit but it downloads them again ... Sigh!

Many thanks

[Todd Zullinger]

Dario Lesca wrote:
> How to I can disable packagekid to download update?
>
> I do not use these packages downloaded uselessly from packagekit into 
> /var/cache/PackageKit/*/*/updates/... because I run sometimes when I 
> want and can, after, reboot, "sudo dnf update".
>
> Unfortunately this command (dnf) do not use the rpm files download from 
> PackageKit but it downloads them again ... Sigh!

You can disable downloading of updates via gsettings:

gsettings set org.gnome.software download-updates false

Doing this prevents rpms from accumulating, but you still end up with 
several hundred megabytes of repo metadata (which isn't ever cleaned 
up for old releases, so it builds up).  I just checked and there was 
800M on my system, with 147M for f26, which I have am not yet running. 
When I do upgrade, it will be via dnf system-upgrade, so the 
PackageKit data does nothing for me.

Alternatively, you can remove PackageKit and gnome-software if you 
don't use them:

sudo dnf remove PackageKit* gnome-software

You'll have to manually clean up the cache dir afterward.  This is 
filed in the fedora and freedesktop.org bug trackers:

https://bugzilla.redhat.com/1306992
    https://bugs.freedesktop.org/80053

Both tickets have been around for a long time without any fixes, 
unfortunately.

[Joe Zeff]

On 12/02/2017 10:54 AM, Todd Zullinger wrote:
> Both tickets have been around for a long time without any fixes, 
> unfortunately.

Judging by the lack of response on some bugzillas I've entered, the 
appropriate resolution would be Closed, DON'TCARE.

[Richard Hughes]

Not DONTCARE, more "really busy with other stuff". If somebody else figures
out a good way to invalidate the cache (probably done in libdnf), I'm happy
to review patches and build packages. It can't *all* be on my shoulders,
right? Richard

On 2 Dec 2017 19:00, "Joe Zeff"  wrote:
> On 12/02/2017 10:54 AM, Todd Zullinger wrote:
> > Both tickets have been around for a long time without any fixes,
> > unfortunately.
>
> Judging by the lack of response on some bugzillas I've entered, the
> appropriate resolution would be Closed, DON'TCARE.
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Joe Zeff]

On 12/02/2017 11:58 AM, Richard Hughes wrote:
> Not DONTCARE, more "really busy with other stuff". If somebody else 
> figures out a good way to invalidate the cache (probably done in 
> libdnf), I'm happy to review patches and build packages. It can't *all* 
> be on my shoulders, right? Richard

That's good to know.  However, over the years I've had bug reports that 
were never followed up or assigned, with the only comment after the 
original report being an announcement that it was being closed at EOL 
for that version.  AFAICT, nobody even looked at them, and the closing 
was simply an autobot.

[stan]

On Sat, 2 Dec 2017 13:54:35 -0500
Todd Zullinger  wrote:
> Dario Lesca wrote:
> > How to I can disable packagekid to download update?
> You can disable downloading of updates via gsettings:
> gsettings set org.gnome.software download-updates false
>
> Doing this prevents rpms from accumulating, but you still end up with 
> several hundred megabytes of repo metadata (which isn't ever cleaned 
> up for old releases, so it builds up).  I just checked and there was 
> 800M on my system, with 147M for f26, which I have am not yet
> running. When I do upgrade, it will be via dnf system-upgrade, so the 
> PackageKit data does nothing for me.
>
> Alternatively, you can remove PackageKit and gnome-software if you 
> don't use them:
> sudo dnf remove PackageKit* gnome-software

Another alternative for disabling PackageKit is to move the file
org.freedesktop.PackageKit.service
to 
org.freedesktop.PackageKit.service.bak
in the /usr/share/dbus-1/system-services/ directory.

You'll also have to move the file
kde-org.freedesktop.PackageKit.service
to
kde-org.freedesktop.PackageKit.service.bak
in the /usr/share/dbus-1/services directory if you have kde installed.

This will have to be done every time PackageKit is updated, but that
isn't all that often.

I keep PackageKit around because even though I like to do my updates
from the command line in a virtual console, I keep Gnome around, and it
is an integral part of Gnome.

[Joe Zeff]

On 12/02/2017 12:17 PM, stan wrote:
> You'll also have to move the file
> kde-org.freedesktop.PackageKit.service
> to
> kde-org.freedesktop.PackageKit.service.bak
> in the /usr/share/dbus-1/services directory if you have kde installed.
>
> This will have to be done every time PackageKit is updated, but that
> isn't all that often.

Wouldn't it be easier to mask the service and be done with it?  Or, if 
that prevents it from running when you need it, disable it.

[stan]

On Sat, 2 Dec 2017 12:35:51 -0800
Joe Zeff  wrote:
> Wouldn't it be easier to mask the service and be done with it?  Or,
> if that prevents it from running when you need it, disable it.

You're right.  I suppose I should get around to doing that.

[Todd Zullinger]

Joe Zeff wrote:
> On 12/02/2017 11:58 AM, Richard Hughes wrote:
> > Not DONTCARE, more "really busy with other stuff". If somebody else 
> > figures out a good way to invalidate the cache (probably done in 
> > libdnf), I'm happy to review patches and build packages. It can't 
> > *all* be on my shoulders, right? Richard
>
> That's good to know.  However, over the years I've had bug reports 
> that were never followed up or assigned, with the only comment after 
> the original report being an announcement that it was being closed 
> at EOL for that version.  AFAICT, nobody even looked at them, and 
> the closing was simply an autobot.

While I'm sure some bugs are not viewed by any maintainers, I'd wager 
that's far fewer than thoss which are viewed and the maintainer simply 
lacks enough time to do anything with it.  There's no way to see if a 
bug was viewed, so as a reporter we can only guess.  It would be ideal 
if all bug reports led to fixes, but that's not likely.

With this particular PackageKit issue, I think that it might be 
lingering for longer because the users most affected are less likely 
to be folks that would dig into the problem and submit patches to the 
appropriate component (as Richard said, the place for a fix might be 
in libdnf).  I know personally, I don't make use of PackageKit and 
Gnome Software, so I "solve" this for myself by removing those 
packages rather than trying to fix it.

It does seem like as long as it's been around that someone who cared 
might have submitted a patch.  I've long told people on projects I 
contribute to that complaints/bug reports/suggestions in unified diff 
format are the best. ;)

[Tom Horsley]

On Sat, 2 Dec 2017 19:21:55 -0500
Todd Zullinger wrote:
> While I'm sure some bugs are not viewed by any maintainers, I'd wager 
> that's far fewer than thoss which are viewed and the maintainer simply 
> lacks enough time to do anything with it.

On the other hand there are the bugs which are on the federal register
of historic bugs, like this one :-).

https://bugzilla.redhat.com/show_bug.cgi?id=451562

[Todd Zullinger]

Tom Horsley wrote:
> On Sat, 2 Dec 2017 19:21:55 -0500 
> Todd Zullinger wrote:
> > While I'm sure some bugs are not viewed by any maintainers, I'd wager 
> > that's far fewer than thoss which are viewed and the maintainer simply 
> > lacks enough time to do anything with it.
>
> On the other hand there are the bugs which are on the federal register 
> of historic bugs, like this one :-).
>
> https://bugzilla.redhat.com/show_bug.cgi?id=451562

Heh, only 9 and a half years?  That's just a baby. ;)

One I've always remembered was #998¹, to check package signatures in 
the installer.  It's been closed for a few years now, but it had the 
alias 'oldest-bug-evar' for a while.  But that wasn't ignored.  It was 
just not something anyone could agree on a proper fix, for various 
reasons.

There are certainly plenty of bugs open for frustratingly long times, 
I'd never argue against that.  I've got some open for the git package 
which are fairly old, so I've felt this from both sides.

But hey, at least this isn't Atlassian.  I've watched bugs for their 
commercial products rot away for years and years, over trivial things 
that paying customers want.

¹ https://bugzilla.redhat.com/show_bug.cgi?id=998

F27: how to disable (or remove) packagekit to download updates

[Dario Lesca]

Il giorno sab, 02/12/2017 alle 19.21 -0500, Todd Zullinger ha scritto:
> I don't make use of PackageKit and 
> Gnome Software, so I "solve" this for myself by removing those 
> packages rather than trying to fix it.

This seem is a finally solution.

Why not do it for all?

Cinnamon o other spin do not use PackageKit and gnome-software, I think
 that Fedora Workstation (Gnome) can do it too

There are for example dnfdragora that can do the gnome-software and
update system jobs

Thanks

F27: how to disable (or remove) packagekit to download updates

[Patrick O'Callaghan]

On Sun, 2017-12-03 at 10:18 +0100, Dario Lesca wrote:
> Il giorno sab, 02/12/2017 alle 19.21 -0500, Todd Zullinger ha scritto:
> > I don't make use of PackageKit and 
> > Gnome Software, so I "solve" this for myself by removing those 
> > packages rather than trying to fix it.
>
> This seem is a finally solution.
>
> Why not do it for all?
>
> Cinnamon o other spin do not use PackageKit and gnome-software, I think
>  that Fedora Workstation (Gnome) can do it too
>
> There are for example dnfdragora that can do the gnome-software and
> update system jobs.

I only ever use dnf from the command line, so removing PackageKit and
the associated cache just gave me back about a GB I didn't even know
was there.

poc

[Rex Dieter]

stan wrote:
> On Sat, 2 Dec 2017 13:54:35 -0500
> Todd Zullinger  wrote:
> > Dario Lesca wrote:
> > > How to I can disable packagekid to download update?
> > You can disable downloading of updates via gsettings:
> > gsettings set org.gnome.software download-updates false
> >
> > Doing this prevents rpms from accumulating, but you still end up with
> > several hundred megabytes of repo metadata (which isn't ever cleaned
> > up for old releases, so it builds up).  I just checked and there was
> > 800M on my system, with 147M for f26, which I have am not yet
> > running. When I do upgrade, it will be via dnf system-upgrade, so the
> > PackageKit data does nothing for me.
> >
> > Alternatively, you can remove PackageKit and gnome-software if you
> > don't use them:
> > sudo dnf remove PackageKit* gnome-software
>
> Another alternative for disabling PackageKit

The poster asked how to disable "download updates", not how to disable 
PackageKit completely (a very different question and solution)

-- Rex