Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Thu, 16 Jun 2016 16:38:44 -0400
Paul Wouters  wrote:

> > On Jun 15, 2016, at 12:51, Stephen Gallagher 
> > wrote:  
> 
> > Traditionally, we've assumed a greater level of understanding for
> > those who use CLI tools as opposed to GUI tools. It's expected that
> > if someone is using DNF directly, it's because they know what they
> > are doing (and what risks that carries). I'm not going to comment
> > on whether that assumption is correct or not,  
> 
> Let me then. The original poster said they stopped using the gui tool
> not because of a different skill level but because they don't want to
> be forced into a reboot now.
> 
> I do the same. A pop up interrupts me and I'm busy. I probably
> forget. Now my system is sure to be out of date.
> 
> Services should be smart enough to restart if one of their dependant
> libraries updates as a security update. Don't we have a super
> competent new fancy init system for these kind of things now?

restart when? If a pop up reminding you to reboot is bothering you and
you forget it, how would one asking to restart apps you are using work?

kevin


pgpcxJKnJvlN3.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Mathieu Bridon]

On Thu, 2016-06-16 at 14:44 +, John Florian wrote:
> > From: Jonathan Wakely [mailto:jwak...@fedoraproject.org]
> > PackageKit and DNF use separate caches, which are not updated at
> > the same time. Try "pkcon refresh" first to update its cache.
> 
> Ok, I tried that but it made no difference.

Try: pkcon refresh force

>   Does pkcon use /etc/yum.repos.d/?

Yes.


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RE: Why GUI software update tool is broken for me

[John Florian]

> From: Jonathan Wakely [mailto:jwak...@fedoraproject.org]
> Sent: Thursday, June 16, 2016 10:14
> To: Development discussions related to Fedora
> Subject: Re: Why GUI software update tool is broken for me
> 
> On 16/06/16 13:39 +, John Florian wrote:
> >Oh cool and here I've been waiting to have this available outside of
> GNOME (as a Plasma user).  However, I'm confused by my first experiment
> with it:
> >
> >
> >$ sudo pkcon update --only-download
> >Getting updates   [=]
> >Finished  [=]
> >No packages require updating to newer versions.
> >
> >$ sudo dnf update
> >No read/execute access in current directory, moving to /
> >Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07 2016.
> >Dependencies resolved.
> >=
> ===
> > Package Arch  Version
> RepositorySize
> >=
> ===
> >Installing:
> > double-conversion   x86_642.0.1-6.fc23
> local-fedora  44 k
> >Upgrading:
> > NetworkManager-l2tp x86_641.0.2-2.fc23
> local-updates 84 k
> > autocorr-en noarch1:5.0.6.2-
> 7.fc23  local-updates204 k
> >
> >util-linux  x86_642.28-2.fc23
> local-updates2.2 M
> >
> >Transaction Summary
> >=
> ===
> >Install   1 Package
> >Upgrade  59 Packages
> >
> >Total download size: 187 M
> >Is this ok [y/N]: n
> >Operation aborted.
> >
> >
> >Why would that be?
> 
> PackageKit and DNF use separate caches, which are not updated at the
> same time. Try "pkcon refresh" first to update its cache.


Ok, I tried that but it made no difference.  Does pkcon use /etc/yum.repos.d/?


--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Michael Catanzaro]

On Thu, 2016-06-16 at 13:39 +, John Florian wrote:
> Oh cool and here I've been waiting to have this available outside of
> GNOME (as a Plasma user).  However, I'm confused by my first
> experiment with it:
> 
> 
> $ sudo pkcon update --only-download
> Getting updates   [=] 
> Finished  [=] 
> No packages require updating to newer versions.
> 
> $ sudo dnf update
> No read/execute access in current directory, moving to /
> Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07
> 2016.
> Dependencies resolved.
> =
> ===
>  Package Arch  Version   
> RepositorySize
> =
> ===
> Installing:
>  double-conversion   x86_642.0.1-
> 6.fc23  local-fedora  44 k
> Upgrading:
>  NetworkManager-l2tp x86_641.0.2-
> 2.fc23  local-updates 84 k
>  autocorr-en noarch1:5.0.6.2-
> 7.fc23  local-updates204 k
> 
> util-linux  x86_642.28-
> 2.fc23   local-updates2.2 M
> 
> Transaction Summary
> =
> ===
> Install   1 Package
> Upgrade  59 Packages
> 
> Total download size: 187 M
> Is this ok [y/N]: n
> Operation aborted.
> 
> 
> Why would that be?

Try 'pkcon refresh' first; my (uninformed) guess is that it doesn't
refresh metadata automatically like dnf does.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Jonathan Wakely]

On 16/06/16 13:39 +, John Florian wrote:

Oh cool and here I've been waiting to have this available outside of GNOME (as 
a Plasma user).  However, I'm confused by my first experiment with it:


$ sudo pkcon update --only-download
Getting updates   [=]
Finished  [=]
No packages require updating to newer versions.

$ sudo dnf update
No read/execute access in current directory, moving to /
Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07 2016.
Dependencies resolved.

Package Arch  Version   
RepositorySize

Installing:
double-conversion   x86_642.0.1-6.fc23  
local-fedora  44 k
Upgrading:
NetworkManager-l2tp x86_641.0.2-2.fc23  
local-updates 84 k
autocorr-en noarch1:5.0.6.2-7.fc23  
local-updates204 k

util-linux  x86_642.28-2.fc23   
local-updates2.2 M

Transaction Summary

Install   1 Package
Upgrade  59 Packages

Total download size: 187 M
Is this ok [y/N]: n
Operation aborted.


Why would that be?


PackageKit and DNF use separate caches, which are not updated at the
same time. Try "pkcon refresh" first to update its cache.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RE: Why GUI software update tool is broken for me

[John Florian]

> From: Stephen Gallagher [mailto:sgall...@redhat.com]
> Sent: Wednesday, June 15, 2016 12:51
> To: devel@lists.fedoraproject.org
> Subject: Re: Why GUI software update tool is broken for me
> 
> 
> People *can* use the command-line to get the reboot behavior:
> ```
> pkcon update --only-download
> pkcon offline-trigger
> reboot

Oh cool and here I've been waiting to have this available outside of GNOME (as 
a Plasma user).  However, I'm confused by my first experiment with it:


$ sudo pkcon update --only-download
Getting updates   [=] 
Finished  [=] 
No packages require updating to newer versions.

$ sudo dnf update
No read/execute access in current directory, moving to /
Last metadata expiration check: 0:03:28 ago on Thu Jun 16 09:30:07 2016.
Dependencies resolved.

 Package Arch  Version  
 RepositorySize

Installing:
 double-conversion   x86_642.0.1-6.fc23 
 local-fedora  44 k
Upgrading:
 NetworkManager-l2tp x86_641.0.2-2.fc23 
 local-updates 84 k
 autocorr-en noarch1:5.0.6.2-7.fc23 
 local-updates204 k

util-linux  x86_642.28-2.fc23   
local-updates2.2 M

Transaction Summary

Install   1 Package
Upgrade  59 Packages

Total download size: 187 M
Is this ok [y/N]: n
Operation aborted.


Why would that be?
--
John Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-15 at 12:41 -0400, Russell Doty wrote:


> > Running tracer for a while can really open your eyes to how many
> > things
> > need restarting after normal updates flow. 
> > 
> > One thing that might make this less annoying to people would be
> > ability
> > to schedule the reboot for some off hours time (2am or something)
> > and
> > also ability (for gnome at least) to restore apps/windows/session
> > again on login. 
> > 
> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?

I believe you are mixing one technical solution to the upgrading
services problem with user use cases.

Yes, one technical solution to the problem of updating packages is
rebooting before updating. However, as the first poster explained this
is NOT what users do or want to do.

So why not just listen and watch what users do and figure a technical
solution that takes into account their use cases?

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 2:17 PM, Stephen Gallagher  wrote:
> On 06/15/2016 03:46 PM, Chris Murphy wrote:
>> I don't understand the technical reason for the 1st reboot. The
>> substantial risk for updates is the user environment. If that's killed
>> off even multi-user.target is far less risk to do updates in. But I
>> don't see why system-update.target can't be isolated from
>> graphical.target rather than mandating a reboot to get there.
>
> I tried to cover this in an earlier post, but the first reboot is to protect
> against things like "user temporarily mounted over /usr/lib/foo so updating 
> the
> foo package isn't actually modifying the persistent system" and "there's a
> memory-leak bug in the kernel so 99% of system RAM is held by kernel space 
> while
> trying to update" or other unpredictable things that can happen according to
> chaos theory when system as complex as a modern Fedora has been running for
> days/weeks/months without a reboot. The first reboot puts the system into a
> (mostly) known state, which is basically a band-aid around a thousand other
> unpredictabilities.

To me this sounds like user sabotage. But lets say I accept this as
sufficiently common that it needs accounting for...

Systemd could unmount everything down to nearly going back to the
initramfs without a reboot, then remount everything per the usual
fstab generator rules just like at startup time, and then commence the
update.

Or probably faster and more reliable would be an nspawn container that
bind mounts the fs per the usual fstab generator rules like at startup
time, and does the offline update in the container environment, which
inside that container would be like a new boot (sorta).

The alternatives appear to have more problems and limitations. We
can't have delayed or scheduled unattended updates on encrypted rootfs
since the user needs to enter a passphrase; or we need a substantially
reworked initramfs that brings up networking much earlier in boot to
connect to a key server in order to unlock rootfs.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 03:46 PM, Chris Murphy wrote:
> I don't understand the technical reason for the 1st reboot. The
> substantial risk for updates is the user environment. If that's killed
> off even multi-user.target is far less risk to do updates in. But I
> don't see why system-update.target can't be isolated from
> graphical.target rather than mandating a reboot to get there.

I tried to cover this in an earlier post, but the first reboot is to protect
against things like "user temporarily mounted over /usr/lib/foo so updating the
foo package isn't actually modifying the persistent system" and "there's a
memory-leak bug in the kernel so 99% of system RAM is held by kernel space while
trying to update" or other unpredictable things that can happen according to
chaos theory when system as complex as a modern Fedora has been running for
days/weeks/months without a reboot. The first reboot puts the system into a
(mostly) known state, which is basically a band-aid around a thousand other
unpredictabilities.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Przemek Klosowski]

On 06/15/2016 09:27 AM, Phil Cameron wrote:

On 06/15/2016 05:16 AM, Emmanuel Seyman wrote:
Id be interested in the original rationale behind this change, as I 
say, I

I believe the rationale is that there was no sane way to update running
applications (firefox, at least, would start not working in interesting
ways when you update it after having launched it).


So when you update an application that is running all you do is 
unlink the file name from the old file and link it to the new file. 
The old file does not go away because it is open by the running 
program. When the program exits, the file is deleted (only if the 
reference count is 0). The next time the program is run it will use 
the new file. 


There's also the issue of all the process-to-process communications: 
desktop bus, systemd and inter-app API, etc. The updated processes may 
speak a different language, and currently there's no unified way to 
express those relationships/dependencies. Some of the data may be even 
in-flight, so static version checking is not enough: consider the 
scenario of appA 1.0 checking and sending a desktop bus message to appB 
1.0; then appB gets updated to 2.0, and doesn't understand the message 
it receives.


I totally agree with you that requiring offline updates with reboot is 
heavy-handed, but it's the only reliable way given the current state of 
technology. You and I live dangerously by delaying those reboots, but 
there's a downside to that.


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 12:43 PM, Stephen Gallagher  wrote:
> On 06/15/2016 02:36 PM, Chris Murphy wrote:
>> On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  
>> wrote:
>>> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
 On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
> Of course, this comes with its own headaches, since of course if you
> are using
> an encrypted drive, you need to enter your password twice: once to
> start the
> update and once for the post-update reboot. A while ago I was working
> on a patch
> to PackageKit that would skip the second reboot and just `systemd
> isolate
> default.target` after the upgrade unless the kernel (or other early
> boot package
> like dracut) was updated. I never finished it, but I could try to dig
> it out and
> pass it on to someone who is interested in continuing it.

 If anyone wants to pick up this work, that would be hugely appreciated,
 as it would allow us to enable full disk encryption by default.

>>>
>>> Well, as I alluded to in another post, I think the disk encryption case is
>>> probably better solved by investing in the development and stabilization of
>>> Tang[1]. Then you would not need to enter the password manually at all.
>>>
>>> [1] https://github.com/npmccallum/tang/blob/master/README.md
>>
>> I see that it's solving a problem, but that problem isn't everyone's
>> problem, and the solution doesn't solve everyone's problem. It
>> requires a tang server, so how does this work for Workstation users?
>> Where is this server?
>>
>> I go to a random coffee shop, I'm on a totally different network, or I
>> travel a lot and I'm on many different networks, how does this scale?
>>
>
> One thing I've been thinkin about is building a tang server as an Android
> application, so that you can decrypt your system simply by having the computer
> make a temporary ad-hoc connection to your cellphone. If it's not within WiFI
> range, the computer doesn't unlock.

OK fine, but the context is doing pk offline updates. If the system
has an encrypted disk, it needs an initramfs that brings up networking
in order to find the tang server on my cell phone. My laptop
definitely does not have network access at all in the
system-update.target.



>> For a computer that needs to update an encrypted disk with the current
>> pk offline update mechanism means networking all has to be baked into
>> the initramfs and autoconfiguring in order for the disk to be
>> decrypted and updates applied.
>>
>
> That makes me nervous as storing the key in something that can survive a 
> reboot
> means that the key is potentially recoverable (such as if the machine gets
> powered off before the second reboot).

I'm not suggesting storing the key in the initramfs. I'm suggesting
networking needs to be brought up in the initramfs to find the tang
server in order to decrypt the drive. That's a substantially different
initramfs than we currently have as far as I'm aware.



>
>> I still think the update needs to happen on logout without first
>> rebooting, and only rebooting after the update is successfully
>> applied. If it were a scheduled/delayed update, then the default
>> behavior would be shutdown after the update is applied rather than
>> reboot.
>>
>> Something like that.
>>
>
> I think ostree is a better fit for you, then. It's atomic; you know before the
> reboot whether the packages will update cleanly or not (and you have a full
> rollback if something in runtime is broken). It requires no special mode to 
> prep
> the update, either.

What? Why does this suddenly need a completely different deployment
system to do something so basic? In particular one that's not yet
really ready for prime time.

Windows and macOS both do updates on logout and then reboot. They do
not reboot and then do updates, and neither of them have the benefit
of rpm-ostree. And they've both been doing this for an ungodly amount
of time, 20 some years give or take.

I don't understand the technical reason for the 1st reboot. The
substantial risk for updates is the user environment. If that's killed
off even multi-user.target is far less risk to do updates in. But I
don't see why system-update.target can't be isolated from
graphical.target rather than mandating a reboot to get there.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 02:36 PM, Chris Murphy wrote:
> On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  
> wrote:
>> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
>>> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
 Of course, this comes with its own headaches, since of course if you
 are using
 an encrypted drive, you need to enter your password twice: once to
 start the
 update and once for the post-update reboot. A while ago I was working
 on a patch
 to PackageKit that would skip the second reboot and just `systemd
 isolate
 default.target` after the upgrade unless the kernel (or other early
 boot package
 like dracut) was updated. I never finished it, but I could try to dig
 it out and
 pass it on to someone who is interested in continuing it.
>>>
>>> If anyone wants to pick up this work, that would be hugely appreciated,
>>> as it would allow us to enable full disk encryption by default.
>>>
>>
>> Well, as I alluded to in another post, I think the disk encryption case is
>> probably better solved by investing in the development and stabilization of
>> Tang[1]. Then you would not need to enter the password manually at all.
>>
>> [1] https://github.com/npmccallum/tang/blob/master/README.md
> 
> I see that it's solving a problem, but that problem isn't everyone's
> problem, and the solution doesn't solve everyone's problem. It
> requires a tang server, so how does this work for Workstation users?
> Where is this server?
> 
> I go to a random coffee shop, I'm on a totally different network, or I
> travel a lot and I'm on many different networks, how does this scale?
> 

One thing I've been thinkin about is building a tang server as an Android
application, so that you can decrypt your system simply by having the computer
make a temporary ad-hoc connection to your cellphone. If it's not within WiFI
range, the computer doesn't unlock.

But yes, the main use-case for Tang is datacenters that don't want their drives
unencrypted at rest (in case they get thrown out or returned for service), but
don't want an interactive prompt when they need to do a rolling update requiring
a reboot.


> For a computer that needs to update an encrypted disk with the current
> pk offline update mechanism means networking all has to be baked into
> the initramfs and autoconfiguring in order for the disk to be
> decrypted and updates applied.
> 

That makes me nervous as storing the key in something that can survive a reboot
means that the key is potentially recoverable (such as if the machine gets
powered off before the second reboot).

> I still think the update needs to happen on logout without first
> rebooting, and only rebooting after the update is successfully
> applied. If it were a scheduled/delayed update, then the default
> behavior would be shutdown after the update is applied rather than
> reboot.
> 
> Something like that.
> 

I think ostree is a better fit for you, then. It's atomic; you know before the
reboot whether the packages will update cleanly or not (and you have a full
rollback if something in runtime is broken). It requires no special mode to prep
the update, either.



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  wrote:
> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
>> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
>>> Of course, this comes with its own headaches, since of course if you
>>> are using
>>> an encrypted drive, you need to enter your password twice: once to
>>> start the
>>> update and once for the post-update reboot. A while ago I was working
>>> on a patch
>>> to PackageKit that would skip the second reboot and just `systemd
>>> isolate
>>> default.target` after the upgrade unless the kernel (or other early
>>> boot package
>>> like dracut) was updated. I never finished it, but I could try to dig
>>> it out and
>>> pass it on to someone who is interested in continuing it.
>>
>> If anyone wants to pick up this work, that would be hugely appreciated,
>> as it would allow us to enable full disk encryption by default.
>>
>
> Well, as I alluded to in another post, I think the disk encryption case is
> probably better solved by investing in the development and stabilization of
> Tang[1]. Then you would not need to enter the password manually at all.
>
> [1] https://github.com/npmccallum/tang/blob/master/README.md

I see that it's solving a problem, but that problem isn't everyone's
problem, and the solution doesn't solve everyone's problem. It
requires a tang server, so how does this work for Workstation users?
Where is this server?

I go to a random coffee shop, I'm on a totally different network, or I
travel a lot and I'm on many different networks, how does this scale?

For a computer that needs to update an encrypted disk with the current
pk offline update mechanism means networking all has to be baked into
the initramfs and autoconfiguring in order for the disk to be
decrypted and updates applied.

I still think the update needs to happen on logout without first
rebooting, and only rebooting after the update is successfully
applied. If it were a scheduled/delayed update, then the default
behavior would be shutdown after the update is applied rather than
reboot.

Something like that.

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 10:31 AM, Stephen Gallagher  wrote:


> Of course, this comes with its own headaches, since of course if you are using
> an encrypted drive, you need to enter your password twice: once to start the
> update and once for the post-update reboot.

Why not change from logout > reboot > update > reboot, to logout >
update > reboot/shutdown? I don't see how unattended/scheduled updates
can really work otherwise. It's probably not sane to stick the KEK
(hash) into NVRAM so it's there for unattended updates even if there's
a sure fire way to remove that entry after the reboot.

> A while ago I was working on a patch
> to PackageKit that would skip the second reboot and just `systemd isolate
> default.target` after the upgrade unless the kernel (or other early boot 
> package
> like dracut) was updated. I never finished it, but I could try to dig it out 
> and
> pass it on to someone who is interested in continuing it.

It's the first reboot that needs to go away in order to solve the
unattended update problem though.

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Bruno Wolff III]

On Wed, Jun 15, 2016 at 10:50:06 -0600,
 Kevin Fenzi  wrote:


Sure and there's encryption as sgallagh mentioned.


There is probably a way to handle the encryption as (at least if there isn't 
a kernel update), as this is done already when switching from initramfs 
to your normal system after getting disk passwords, during normal boots 
already.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:31 PM, Stephen Gallagher wrote:
> 
> 
> The justification for restarting both before and after installation exists and
> it does make some sense in certain circumstances.
> 
> Basically, the problem is that any number of things can change in the state of
> the system while it has been running that are impossible to predict. For
> example, the system's memory (and swap) could be almost all used up, leading 
> to
> unpredictable behavior while processing the update and %pre/%post scripts. 
> Also,
> a user may have manually played around with the mount table, resulting in some
> directory paths being unmounted or mounted over that the upgrade would write
> into. By forcing the system to reboot into a limited environment, it puts the
> system into something much closer to a known state which is less likely to
> experience an unrecoverable error. (Ever had a runaway log fill up a disk 
> during
> a dnf update? Not a good thing.)
> 
> 
> Of course, this comes with its own headaches, since of course if you are using
> an encrypted drive, you need to enter your password twice: once to start the
> update and once for the post-update reboot. A while ago I was working on a 
> patch
> to PackageKit that would skip the second reboot and just `systemd isolate
> default.target` after the upgrade unless the kernel (or other early boot 
> package
> like dracut) was updated. I never finished it, but I could try to dig it out 
> and
> pass it on to someone who is interested in continuing it.
> 

I meant to also include a section here about how this problem is also completely
solved by ostree[1] (the technology used by Project Atomic and upcoming Fedora
Workstation changes) which works by prepping all of the state of the system
while the current system is running. Then the system is rebooted once directly
into the new system, atomically. This leaves no room at all for upgrade failures
leaving the system unusable.

Historically, there was a tradeoff here, because it was difficult to use ostree
for upgrades with a custom set of packages on the system, but recently a lot of
work has gone into doing package layering as well, so it's well on its way to
becoming a complete replacement of the traditional package-by-package updater.


[1] https://github.com/projectatomic/rpm-ostree/blob/master/README.md



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
>> Of course, this comes with its own headaches, since of course if you
>> are using
>> an encrypted drive, you need to enter your password twice: once to
>> start the
>> update and once for the post-update reboot. A while ago I was working
>> on a patch
>> to PackageKit that would skip the second reboot and just `systemd
>> isolate
>> default.target` after the upgrade unless the kernel (or other early
>> boot package
>> like dracut) was updated. I never finished it, but I could try to dig
>> it out and
>> pass it on to someone who is interested in continuing it.
> 
> If anyone wants to pick up this work, that would be hugely appreciated,
> as it would allow us to enable full disk encryption by default.
> 

Well, as I alluded to in another post, I think the disk encryption case is
probably better solved by investing in the development and stabilization of
Tang[1]. Then you would not need to enter the password manually at all.

[1] https://github.com/npmccallum/tang/blob/master/README.md



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Bruno Wolff III]

On Wed, Jun 15, 2016 at 10:49:18 -0600,
 Kevin Fenzi  wrote:


Well, it's different historical behavior/tradeoffs. dnf assumes you
will reboot as you need to / restart apps that need restarting.


And there is an extension that will tell you what needs to be restarted.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Michael Catanzaro]

On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
> Of course, this comes with its own headaches, since of course if you
> are using
> an encrypted drive, you need to enter your password twice: once to
> start the
> update and once for the post-update reboot. A while ago I was working
> on a patch
> to PackageKit that would skip the second reboot and just `systemd
> isolate
> default.target` after the upgrade unless the kernel (or other early
> boot package
> like dracut) was updated. I never finished it, but I could try to dig
> it out and
> pass it on to someone who is interested in continuing it.

If anyone wants to pick up this work, that would be hugely appreciated,
as it would allow us to enable full disk encryption by default.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 12:41:42 -0400
Russell Doty  wrote:

> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?

Well, it's different historical behavior/tradeoffs. dnf assumes you
will reboot as you need to / restart apps that need restarting. 

> We have an observed difference between what is permitted in the cli
> tool and what is permitted in the gui tool. Why this difference?

History and tradeoffs. dnf (and yum before it) have always applied
updates when you asked without a reboot, and they have decided that the
problems with doing so are acceptable. 

I'd personally be against changing this behavior now, but it might be
nice to add a way to opt in with dnf... ie, a 'dnf update --offline' or
something to apply the updates the way that gnome-software does for
those that want that. 

kevin


pgpKjEzA5RRwS.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:41 PM, Russell Doty wrote:
> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?
> 
> We have an observed difference between what is permitted in the cli
> tool and what is permitted in the gui tool. Why this difference?


Traditionally, we've assumed a greater level of understanding for those who use
CLI tools as opposed to GUI tools. It's expected that if someone is using DNF
directly, it's because they know what they are doing (and what risks that
carries). I'm not going to comment on whether that assumption is correct or not,
just that it's what generally determines the mode of operation.

People *can* use the command-line to get the reboot behavior:
```
pkcon update --only-download
pkcon offline-trigger
reboot
```

That said, there *is* value to allowing people to update individual things
without forcing a system reboot if they know enough to do so. (For example, if I
am updating a leaf-node GUI application that is not currently running).

I think it makes sense however to leave the graphical tool to follow best and
safest practice. Advanced users can use the CLI tools. I think we'd see *far*
more angry pitchforks if we took away that decision from DNF.



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 10:45:12 -0600
Chris Murphy  wrote:

> Laptop users need reminding. A scheduled update has a decent chance of
> not happening because the laptop is sleeping.

Sure and there's encryption as sgallagh mentioned. 

> The ability for applications to save their state would be great; and
> to autolaunch at next login. If the user were to explicitly quit the
> application, part of its cleanup would be to unset that autolaunch. So
> it'd need some granularity to distinguish between 'next login
> autolaunch' and 'user specified persistent autolaunch'.

Yeah, I don't know if thats planned or just not going to happen. 

kevin
 



pgp_IadBGNICG.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 10:27 AM, Kevin Fenzi  wrote:
> On Wed, 15 Jun 2016 17:39:32 +0200
> Kamil Dudka  wrote:
>
>> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
>> > Dne 15.6.2016 v 10:14 Ade napsal(a):
>> > > Why is this?  Well some time ago the behaviour of the tool
>> > > changed and now the only way to proceed is to click in "Restart
>> > > and Install" and this is NEVER what I want to do. I never want to
>> > > reboot my desktop just to apply updates, Id rather apply all the
>> > > updates and reboot to bring in the new kernel (if there is one)
>> > > when I have the time
>> > Imagine two regular updates.
>> >
>> > First you update mariadb-server package. %post is smart and it will
>> > condrestart the mariadb service. However...
>> >
>> > Next day you update "pam" package which
>> > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
>> > Unless you restart your computer your mariadb server will continue
>> > to use old (and maybe insecure) libpam.so. Or unless you use
>> > dnf-plugins-extras-tracer:
>> > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
>>
>> It is a reason to restart the system (or just the services of
>> interest) _after_ installing the update, but not before installing
>> the update.
>
> I think it's a combination of all these:
>
> * If you simply apply updates and don't restart everything that uses
>   the things updated you will not be taking advantage of the security
>   or bugfixes. If those things are used by a lot of your apps,
>   restarting each one is tedious and/or as disruptive as just rebooting
>   anyhow.
>
> * Even though live updates work 'pretty well' there will always be a
>   number of corner cases where applications will not function correctly
>   after they are updated but before they are restarted. Directories or
>   resources they need may have changed, etc.
>
> Running tracer for a while can really open your eyes to how many things
> need restarting after normal updates flow.
>
> One thing that might make this less annoying to people would be ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login.

Laptop users need reminding. A scheduled update has a decent chance of
not happening because the laptop is sleeping.

The ability for applications to save their state would be great; and
to autolaunch at next login. If the user were to explicitly quit the
application, part of its cleanup would be to unset that autolaunch. So
it'd need some granularity to distinguish between 'next login
autolaunch' and 'user specified persistent autolaunch'.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Russell Doty]

On Wed, 2016-06-15 at 10:27 -0600, Kevin Fenzi wrote:
> On Wed, 15 Jun 2016 17:39:32 +0200
> Kamil Dudka  wrote:
> 
> > 
> > On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> > > 
> > > Dne 15.6.2016 v 10:14 Ade napsal(a):  
> > > > 
> > > > Why is this?  Well some time ago the behaviour of the tool
> > > > changed and now the only way to proceed is to click in "Restart
> > > > and Install" and this is NEVER what I want to do. I never want
> > > > to
> > > > reboot my desktop just to apply updates, Id rather apply all
> > > > the
> > > > updates and reboot to bring in the new kernel (if there is one)
> > > > when I have the time  
> > > Imagine two regular updates.
> > > 
> > > First you update mariadb-server package. %post is smart and it
> > > will
> > > condrestart the mariadb service. However...
> > > 
> > > Next day you update "pam" package which
> > > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
> > > Unless you restart your computer your mariadb server will
> > > continue
> > > to use old (and maybe insecure) libpam.so. Or unless you use
> > > dnf-plugins-extras-tracer:
> > > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html  
> > It is a reason to restart the system (or just the services of
> > interest) _after_ installing the update, but not before installing
> > the update.
> I think it's a combination of all these:
> 
> * If you simply apply updates and don't restart everything that uses
>   the things updated you will not be taking advantage of the security
>   or bugfixes. If those things are used by a lot of your apps,
>   restarting each one is tedious and/or as disruptive as just
> rebooting
>   anyhow. 
> 
> * Even though live updates work 'pretty well' there will always be a
>   number of corner cases where applications will not function
> correctly
>   after they are updated but before they are restarted. Directories
> or
>   resources they need may have changed, etc. 
> 
> Running tracer for a while can really open your eyes to how many
> things
> need restarting after normal updates flow. 
> 
> One thing that might make this less annoying to people would be
> ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login. 
> 
Note that the original poster says that he runs dnf -update from the
command line because it allows him to do what he wants.

Based on the information discussed in this thread, shouldn't dnf also
force a reboot before updates?

We have an observed difference between what is permitted in the cli
tool and what is permitted in the gui tool. Why this difference?
> kevin
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:27 PM, Kevin Fenzi wrote:
> One thing that might make this less annoying to people would be ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login. 
> 

Scheduling the reboot for off-hours doesn't help much if you're following good
security practice and encrypting your drives, though. unless of course you are
set up to use something like Tang[1] to manage your drive encryption instead of
a password prompt.


[1] https://github.com/npmccallum/tang/blob/master/README.md



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 11:39 AM, Kamil Dudka wrote:
> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
>> Dne 15.6.2016 v 10:14 Ade napsal(a):
>>> Why is this?  Well some time ago the behaviour of the tool changed and now
>>> the only way to proceed is to click in "Restart and Install" and this is
>>> NEVER what I want to do. I never want to reboot my desktop just to apply
>>> updates, Id rather apply all the updates and reboot to bring in the new
>>> kernel (if there is one) when I have the time
>> Imagine two regular updates.
>>
>> First you update mariadb-server package. %post is smart and it will
>> condrestart the mariadb service. However...
>>
>> Next day you update "pam" package which provides /usr/lib64/libpam.so.0
>> which is used by mariadb service. Unless you restart your computer your
>> mariadb server will continue to use old (and maybe insecure) libpam.so. Or
>> unless you use dnf-plugins-extras-tracer:
>>   http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
> 
> It is a reason to restart the system (or just the services of interest) 
> _after_ installing the update, but not before installing the update.


The justification for restarting both before and after installation exists and
it does make some sense in certain circumstances.

Basically, the problem is that any number of things can change in the state of
the system while it has been running that are impossible to predict. For
example, the system's memory (and swap) could be almost all used up, leading to
unpredictable behavior while processing the update and %pre/%post scripts. Also,
a user may have manually played around with the mount table, resulting in some
directory paths being unmounted or mounted over that the upgrade would write
into. By forcing the system to reboot into a limited environment, it puts the
system into something much closer to a known state which is less likely to
experience an unrecoverable error. (Ever had a runaway log fill up a disk during
a dnf update? Not a good thing.)


Of course, this comes with its own headaches, since of course if you are using
an encrypted drive, you need to enter your password twice: once to start the
update and once for the post-update reboot. A while ago I was working on a patch
to PackageKit that would skip the second reboot and just `systemd isolate
default.target` after the upgrade unless the kernel (or other early boot package
like dracut) was updated. I never finished it, but I could try to dig it out and
pass it on to someone who is interested in continuing it.



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 17:39:32 +0200
Kamil Dudka  wrote:

> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> > Dne 15.6.2016 v 10:14 Ade napsal(a):  
> > > Why is this?  Well some time ago the behaviour of the tool
> > > changed and now the only way to proceed is to click in "Restart
> > > and Install" and this is NEVER what I want to do. I never want to
> > > reboot my desktop just to apply updates, Id rather apply all the
> > > updates and reboot to bring in the new kernel (if there is one)
> > > when I have the time  
> > Imagine two regular updates.
> > 
> > First you update mariadb-server package. %post is smart and it will
> > condrestart the mariadb service. However...
> > 
> > Next day you update "pam" package which
> > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
> > Unless you restart your computer your mariadb server will continue
> > to use old (and maybe insecure) libpam.so. Or unless you use
> > dnf-plugins-extras-tracer:
> > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html  
> 
> It is a reason to restart the system (or just the services of
> interest) _after_ installing the update, but not before installing
> the update.

I think it's a combination of all these:

* If you simply apply updates and don't restart everything that uses
  the things updated you will not be taking advantage of the security
  or bugfixes. If those things are used by a lot of your apps,
  restarting each one is tedious and/or as disruptive as just rebooting
  anyhow. 

* Even though live updates work 'pretty well' there will always be a
  number of corner cases where applications will not function correctly
  after they are updated but before they are restarted. Directories or
  resources they need may have changed, etc. 

Running tracer for a while can really open your eyes to how many things
need restarting after normal updates flow. 

One thing that might make this less annoying to people would be ability
to schedule the reboot for some off hours time (2am or something) and
also ability (for gnome at least) to restore apps/windows/session
again on login. 

kevin


pgp31Fwwlycbk.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 7:27 AM, Phil Cameron  wrote:

> On 06/15/2016 05:16 AM, Emmanuel Seyman wrote:
>
>> * Ade [15/06/2016 10:14] :
>>
>>> Id be interested in the original rationale behind this change, as I say,
>>> I
>>>
>> I believe the rationale is that there was no sane way to update running
>> applications (firefox, at least, would start not working in interesting
>> ways when you update it after having launched it).
>>
>> Emmanuel
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
> I think you misunderstand. A file remains in the system until it is no
> longer needed. The file and its name are two separate things. The name can
> be unlinked from a file and linked to another file ( as is done by update).
> The file remains around until all of it's names are unlinked and no process
> has it open. The reference count is incremented every time the file gets a
> name or is opened by some process. It is decremented every time a name is
> unlinked and every time it is closed. It is quietly deleted when the
> reference count finally goes to zero.
>
> So when you update an application that is running all you do is unlink the
> file name from the old file and link it to the new file. The old file does
> not go away because it is open by the running program. When the program
> exits, the file is deleted (only if the reference count is 0). The next
> time the program is run it will use the new file.


I think you're referring to VFS tracking open files, and assumes the update
process is entirely atomic, i.e. when updating a binary, an entirely new
binary is written to disk rather than overwriting the old one. If the old
one is overwritten then the VFS is going to point to the new one, the old
one is simply gone. I have no idea if dnf/rpm binary updates files
themselves atomically (the entire update process is definitely not atomic)
or if they're overwritten. I'm pretty sure they're overwritten.

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Kamil Dudka]

On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> Dne 15.6.2016 v 10:14 Ade napsal(a):
> > Why is this?  Well some time ago the behaviour of the tool changed and now
> > the only way to proceed is to click in "Restart and Install" and this is
> > NEVER what I want to do. I never want to reboot my desktop just to apply
> > updates, Id rather apply all the updates and reboot to bring in the new
> > kernel (if there is one) when I have the time
> Imagine two regular updates.
> 
> First you update mariadb-server package. %post is smart and it will
> condrestart the mariadb service. However...
> 
> Next day you update "pam" package which provides /usr/lib64/libpam.so.0
> which is used by mariadb service. Unless you restart your computer your
> mariadb server will continue to use old (and maybe insecure) libpam.so. Or
> unless you use dnf-plugins-extras-tracer:
>   http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html

It is a reason to restart the system (or just the services of interest) 
_after_ installing the update, but not before installing the update.

Kamil
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Miroslav Suchý]

Dne 15.6.2016 v 10:14 Ade napsal(a):
> Why is this?  Well some time ago the behaviour of the tool changed and now 
> the only way to proceed is to click in
> "Restart and Install" and this is NEVER what I want to do. I never want to 
> reboot my desktop just to apply updates, Id
> rather apply all the updates and reboot to bring in the new kernel (if there 
> is one) when I have the time

Imagine two regular updates.

First you update mariadb-server package. %post is smart and it will condrestart 
the mariadb service. However...

Next day you update "pam" package which provides /usr/lib64/libpam.so.0 which 
is used by mariadb service.
Unless you restart your computer your mariadb server will continue to use old 
(and maybe insecure) libpam.so.
Or unless you use dnf-plugins-extras-tracer:
  http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Jonathan Wakely]

On 15/06/16 09:27 -0400, Phil Cameron wrote:
So when you update an application that is running all you do is unlink 
the file name from the old file and link it to the new file. The old 
file does not go away because it is open by the running program. When 
the program exits, the file is deleted (only if the reference count is 
0). The next time the program is run it will use the new file.


If only it was always that simple.

https://bugzilla.mozilla.org/show_bug.cgi?id=1213224

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Phil Cameron]

On 06/15/2016 05:16 AM, Emmanuel Seyman wrote:

* Ade [15/06/2016 10:14] :

Id be interested in the original rationale behind this change, as I say, I

I believe the rationale is that there was no sane way to update running
applications (firefox, at least, would start not working in interesting
ways when you update it after having launched it).

Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
I think you misunderstand. A file remains in the system until it is no 
longer needed. The file and its name are two separate things. The name 
can be unlinked from a file and linked to another file ( as is done by 
update). The file remains around until all of it's names are unlinked 
and no process has it open. The reference count is incremented every 
time the file gets a name or is opened by some process. It is 
decremented every time a name is unlinked and every time it is closed. 
It is quietly deleted when the reference count finally goes to zero.


So when you update an application that is running all you do is unlink 
the file name from the old file and link it to the new file. The old 
file does not go away because it is open by the running program. When 
the program exits, the file is deleted (only if the reference count is 
0). The next time the program is run it will use the new file.


phil
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Björn Persson]

Joachim Backes  wrote:
> On 06/15/16 11:16, Emmanuel Seyman wrote:
> > I believe the rationale is that there was no sane way to update running
> > applications (firefox, at least, would start not working in interesting
> > ways when you update it after having launched it).  
> 
> What if you updating the bash? It's always running :-;

Running Bash processes will continue running unaffected. Bash instances
started after the update will run the updated version. Neither will
break. To ensure that you're not using the old version you need to
terminate all your Bash processes and start new ones, which can be done
by rebooting, but that can be done at your convenience after the update.

Firefox could have worked this way too, if it had been designed better.

I have some understanding for why Gnome Software tries to enforce a
reboot though. (I assume that's the GUI tool Ade was talking about.)
Gnome 3 is intended for the "Aunt Tillie" kind of user – nontechnical
people who don't know the first thing about computers. Those users
can't be expected to understand or remember that they need to reboot if
certain central components were updated. They'd postpone the reboot
forever because that's the most convenient.

Björn Persson


pgpaMVmj5rVOy.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Emmanuel Seyman]

* Joachim Backes [15/06/2016 11:22] :
>
> What if you updating the bash? It's always running :-;

No, it isn't. These days, Gnome Software prompts you to reboot,
reboots the machine in a safe mode where nothing much is running,
updates everything, then boots back in normal mode (this is my
understanding of the process so YMMV).

Bash is only running if you update via dnf like Ade or myself.

Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Joachim Backes]

On 06/15/16 11:16, Emmanuel Seyman wrote:

* Ade [15/06/2016 10:14] :


Id be interested in the original rationale behind this change, as I say, I


I believe the rationale is that there was no sane way to update running
applications (firefox, at least, would start not working in interesting
ways when you update it after having launched it).


What if you updating the bash? It's always running :-;

Joachim Backes

--

Fedora release 24 (Twenty Four)
Kernel-4.5.7-300.fc24.x86_64


Joachim Backes 
http://www-user.rhrk.uni-kl.de/~backes/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Emmanuel Seyman]

* Ade [15/06/2016 10:14] :
>
> Id be interested in the original rationale behind this change, as I say, I

I believe the rationale is that there was no sane way to update running
applications (firefox, at least, would start not working in interesting
ways when you update it after having launched it).

Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-15 at 10:14 +0200, Ade wrote:
> Hi all
> 
> I dont really want this to be a negative post, just want to share
> something in order to start a healthy discussion
> 
> Background
> Im a Fedora desktop user, have been for many years, going all the way
> back to Fedora Core 1 - I use Fedora on a daily basis, its my main
> (in fact only OS)
> 
> Issue
> Im very comfortable with the CLI, but spend the majority of the time
> in the GUI - I noticed a behaviour change in myself recently - I now
> NEVER use the GUI Software Update tool. I noticed the other day but
> its been like this for quite some time. 
> 
> My workflow is - the GUI tool tells me there are updates, I dismiss
> it and open a terminal and do sudo dnf update -y    
> 
> Why is this?  Well some time ago the behaviour of the tool changed
> and now the only way to proceed is to click in "Restart and Install"
> and this is NEVER what I want to do. I never want to reboot my
> desktop just to apply updates, Id rather apply all the updates and
> reboot to bring in the new kernel (if there is one) when I have the
> time
> I cant help but feel this is, to me anyway,. a broken design, are
> there others that feel the same or am I alone on this

+1

I was always wondering which user scenario the restart and install
covers. On several occasions I could afford an "install + shutdown"
(i.e., when I'm leaving the PC), but restart and install is something
I've never needed/used.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Why GUI software update tool is broken for me

[Ade]

Hi all

I dont really want this to be a negative post, just want to share something
in order to start a healthy discussion

*Background*
Im a Fedora desktop user, have been for many years, going all the way back
to Fedora Core 1 - I use Fedora on a daily basis, its my main (in fact only
OS)

*Issue*
Im very comfortable with the CLI, but spend the majority of the time in the
GUI - I noticed a behaviour change in myself recently - I now NEVER use the
GUI Software Update tool. I noticed the other day but its been like this
for quite some time.

My workflow is - the GUI tool tells me there are updates, I dismiss it and
open a terminal and do sudo dnf update -y

Why is this?  Well some time ago the behaviour of the tool changed and now
the only way to proceed is to click in "Restart and Install" and this is
NEVER what I want to do. I never want to reboot my desktop just to apply
updates, Id rather apply all the updates and reboot to bring in the new
kernel (if there is one) when I have the time

I cant help but feel this is, to me anyway,. a broken design, are there
others that feel the same or am I alone on this

Id be interested in the original rationale behind this change, as I say, I
dont wont to start a bitching session, just interested in why this change
happened

Adrian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org