Proposed F19 Feature: Fedora Upgrade - using yum

[Jaroslav Reznik]

= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade

Feature owner(s):  Miroslav Suchý <msuchy(a)redhat.com&gt; 

Upgrade Fedora to next version using yum upgrade. 

== Detailed description ==
In past (until Fedora 17) we could upgrade Fedora using Anaconda Upgrade and 
PreUpgrade.

Now (in Fedora 18) we have only FedUp and previous methods are obsoleted.

I propose to have FedUp and FedoraUpgrade in Fedora 19.

FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line 
upgrade). Some devels say that offline upgrade is only way. But on-line upgrade 
is possible. E.g in Debian world it is even prefered method. In Fedora exist 
upgrade using yum as unofficial method for long time.

A lot of people are using upgrade using yum for long time and the "problem 
ratio" was at least on pair with Anaconda upgrade. In fact most problems comes 
from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade 
user get file conflict. Once these problems are reported and fixed the upgrade is 
without problem.

And since FedUp is just different approach to yum-upgrade, FedUp will benefit 
from fixes on FedoraUpgrade (and vice versa).

I propose to support both FedUp and FedoraUpgrade and give user option.

If this method will be tested by FedoraQA, then I believe this upgrade method 
can be safely recommended to user. 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Lennart Poettering]

On Wed, 23.01.13 18:04, Jaroslav Reznik (jreznik(a)redhat.com) wrote:

>  FedUp is in fact yum-upgrade as well, but in dracut environment (aka
> off-line 
>  upgrade). Some devels say that offline upgrade is only way. But on-line upgrade 
>  is possible. E.g in Debian world it is even prefered method. In Fedora exist 
>  upgrade using yum as unofficial method for long time.
>  
>  A lot of people are using upgrade using yum for long time and the "problem 
>  ratio" was at least on pair with Anaconda upgrade. In fact most problems comes 
>  from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade 
>  user get file conflict. Once these problems are reported and fixed the upgrade is 
>  without problem. 
I'd strongly say "NO" to this. Not because I would have a problem with
people doing non-fedup upgrades (I tend to upgrade my machines with yum
myself, too). However, making this officially supported, and advertising
this as a feature appears to be the wrong move to me.

The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.

Doing manual on-line upgrades with "yum distro-sync" is a fine
thing to do, but this requires people to understand that things might go
wrong, and requires a certain skill set from people so that they know
what to do if things go wrong (like for example knowing how to kill
firefox from the command line). But by making this an officially
supported feature fedora would suggest this as something that would work
for anybody, without any additional knowledge, and Fedora would have to
deal with the additional support work/bug burden this creates.

It's OK if an RPM for this enters the archive, it's OK if people who
know how to fix their machines use this, it's OK if people suggest this
as hidden functionality. But I think it would be a big mistake for
Fedora to advertise this as official feature, and to accept the support
burden this creates.

Fedora doesn't have unlimited resources, we have more than enough bugs
to fix anyway, making online updates an officially supported feature
would amplify this disparity.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Kay Sievers]

On Wed, Jan 23, 2013 at 7:50 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Wed, 23.01.13 18:04, Jaroslav Reznik (jreznik(a)redhat.com) wrote:
>
> > FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
> > upgrade). Some devels say that offline upgrade is only way. But on-line upgrade
> > is possible. E.g in Debian world it is even prefered method. In Fedora exist
> > upgrade using yum as unofficial method for long time.
> >
> > A lot of people are using upgrade using yum for long time and the "problem
> > ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
> > from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade
> > user get file conflict. Once these problems are reported and fixed the upgrade is
> > without problem.
>
>  I'd strongly say "NO" to this. Not because I would have a problem with
>  people doing non-fedup upgrades (I tend to upgrade my machines with yum
>  myself, too). However, making this officially supported, and advertising
>  this as a feature appears to be the wrong move to me.
>
>  The thing is that doing on-line updates only works for stuff you can
>  restart, and that doesn't mind that things are not atomically
>  updated. However, much (most?) of our code isn't like that. Anybody who
>  tried to update the Firefox RPM while it is running knows that this
>  doesn't end well, and you frequently have to manually kill firefox to
>  get it back into a usual state.
>
>  Doing manual on-line upgrades with "yum distro-sync" is a fine
>  thing to do, but this requires people to understand that things might go
>  wrong, and requires a certain skill set from people so that they know
>  what to do if things go wrong (like for example knowing how to kill
>  firefox from the command line). But by making this an officially
>  supported feature fedora would suggest this as something that would work
>  for anybody, without any additional knowledge, and Fedora would have to
>  deal with the additional support work/bug burden this creates.
>
>  It's OK if an RPM for this enters the archive, it's OK if people who
>  know how to fix their machines use this, it's OK if people suggest this
>  as hidden functionality. But I think it would be a big mistake for
>  Fedora to advertise this as official feature, and to accept the support
>  burden this creates.
>
>  Fedora doesn't have unlimited resources, we have more than enough bugs
>  to fix anyway, making online updates an officially supported feature
>  would amplify this disparity. 
I, speaking for the stuff I'm involved and maintain, will certainly
not work on things to make online upgrades work correctly, if they
don't for whatever reason.

It's a huge lie to pretend we can reliably do this, and just a
I-hope-it-will-work-out thing not based on the technical reality.
Anybody who claims this can and will always work flawlessly as a
general model, seems not to understand the problems well enough.

We all do these kind of updates ourselves, sure, and we surely don't
want to make that impossible in the future; but it's nothing I
personally would *ever* want to *support* on other people's systems.

There is a reason we partly switched to offline updates now, it can at
least work in the theory behind it, unlike the online updates. Please
never try to *support* that officially, it cannot and will not work
out.

Thanks,
Kay

[Michael Scherer]

Le mercredi 23 janvier 2013 à 19:50 +0100, Lennart Poettering a écrit :
>  On Wed, 23.01.13 18:04, Jaroslav Reznik (jreznik(a)redhat.com) wrote:
>  
>  > FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line 
>  > upgrade). Some devels say that offline upgrade is only way. But on-line upgrade 
>  > is possible. E.g in Debian world it is even prefered method. In Fedora exist 
>  > upgrade using yum as unofficial method for long time.
>  > 
>  > A lot of people are using upgrade using yum for long time and the "problem 
>  > ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
>
>  > from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade 
>  > user get file conflict. Once these problems are reported and fixed the upgrade is 
>  > without problem.
>
>  [...]
>  It's OK if an RPM for this enters the archive, it's OK if people who
>  know how to fix their machines use this, it's OK if people suggest this
>  as hidden functionality. But I think it would be a big mistake for
>  Fedora to advertise this as official feature, and to accept the support
>  burden this creates. 
Yet, there is enough people ( like you, like me ) using it. While I
agree that pushing this as fully supported in all cases do not seems a
wise move, maybe we could restrict to some use cases, like "upgrading a
lxc container with a minimal downtime", or sometimes like that, and see
how it goes. 

And the more I think about, the more I think we should rather have a SIG
than a feature ( like the move of arm to PA ) :

- this need to have a specific set of ressources for QA, etc. We cannot
increase QA by magic and should not increase the workload of the current
team, but we cannot forbid to people to test what they want. So as long
as the interested people organize themselves, this would not be a issue

- this is a effort that must be sustained in time. So we need a team of
people to do it. IE, a SIG, not a Feature.

And if this permit to find bugs sooner, this is good because AFAIK fedup
use distro-sync as well.

And having a SIG permit also to direct people who want to do it to see
with the SIG, who can explain the caveats better than "this is not
supported" as it currently is.

If this work for Rawhide (since Kevin is IMHO on a good track for that),
it can work for that too.

-- 
Michael Scherer

[Miroslav Suchý]

On 01/23/2013 07:50 PM, Lennart Poettering wrote:
>  The thing is that doing on-line updates only works for stuff you can
>  restart, and that doesn't mind that things are not atomically
>  updated. However, much (most?) of our code isn't like that. Anybody who 
What could not be restarted? And what we can do to fix that?

If this work for Debian/Ubuntu, why it could not work for Fedora?

>  tried to update the Firefox RPM while it is running knows that this
>  doesn't end well, and you frequently have to manually kill firefox to
>  get it back into a usual state. 
Interesting. Although I'm doing yum upgrade quite frequently I do not 
have such experience.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Bill Nottingham]

Miroslav Suchý (msuchy(a)redhat.com) said: 
>  On 01/23/2013 07:50 PM, Lennart Poettering wrote:
>  >The thing is that doing on-line updates only works for stuff you can
>  >restart, and that doesn't mind that things are not atomically
>  >updated. However, much (most?) of our code isn't like that. Anybody who
>  
>  What could not be restarted? And what we can do to fix that?
>  
>  If this work for Debian/Ubuntu, why it could not work for Fedora? 
Essentially, the idea of a major release is to do the sorts of upgrades
that don't work cleanly on a running system. Examples would be:

- mysql database version upgrade (or similar upgrades that require
  a format conversion)
- switching out the system python interpreter version
- switching from a static /dev to udev
- switching init systems
- switching a script from being sysv to being a systemd service
- refactoring of a systemd service if necessary
- /usr move
- introduction of changes that require a new kernel subsystem mount
  point, or the move of one (/selinux to /sys/fs/selinux, for example)

None of these things are things that will work perfectly reliably in an
on-line upgrade mechanism.

Bill

[Lennart Poettering]

On Thu, 24.01.13 15:28, Miroslav Suchý (msuchy(a)redhat.com) wrote:

>  On 01/23/2013 07:50 PM, Lennart Poettering wrote:
>  >The thing is that doing on-line updates only works for stuff you can
>  >restart, and that doesn't mind that things are not atomically
>  >updated. However, much (most?) of our code isn't like that. Anybody who
>  
>  What could not be restarted? And what we can do to fix that? 
The kernel for starters, dbus too, bash, ssh daemon processes of open
connections, gdm, ... 

If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...

Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?

Of course, you can say that it's OK if those processes just stay
running, and then are updated when the user reboots the machine the next
time, or restarts his apps the next time, or logs out and back in the
next time, but until then you have versions of these programs in memory
that might not be able to find their own resources anymore, because
those got replaced, or they might find them in different versions than
they might expect.

But let's pretend for a minute that there was a way how you could
restart the kernel, dbus, and everything else without taking the machine
or user session down, how would you figure out *what* precisely you need
to restart? There are some scripts floating around that try to figure
that out via "ldd", but that's very incomplete, because that assumes the
only kind of dependency that was relevant were shared library deps --
but there are more than that and in times of dlopen() ldd doesn't work
comprehensively for those anyway. Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation. And much of that might be continously
mapped into memory, and others only temporarily. How are you going to
figure out that?

I mean, here's an example: let's say openssl is updated, which is pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your system,
and they all dlopen() the NSS module. So how do you now figure out which
ones that are and how do you then figure out what the heck you need to
do to get them restarted?

So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable openssl version is still in memory,
still actively used, even though your update script exited successfully
leaving the user under the impression that all was good now and that
after he made this upgrade his machine was not vulnerable anymore. 

So you kinda promised the user online updates, but you actually just
updated a number of things, and leaving the biggest chunk of code in
memory still, without a chance to restart it or even figure out what it
is that you left unrestarted. 

Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't
"online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...

>  If this work for Debian/Ubuntu, why it could not work for Fedora?
Will, because it doesn't work for them either. It works "well enough"
for the knowledgeable, and that's what they focus on.

I mean, just think about it: every new Fedora release sofar came with a
new kernel version. The only way how to upgrade the kernel probably is
by taking the machine offline for a while and rebooting. If you are
willing to ignore everything I said above, how would your script keep
the machine online during a kernel upgrade?

>  >tried to update the Firefox RPM while it is running knows that
> this
>  >doesn't end well, and you frequently have to manually kill firefox to
>  >get it back into a usual state.
>  
>  Interesting. Although I'm doing yum upgrade quite frequently I do
>  not have such experience. 
Well, sooner or later you'll run into that with Firefox, or with some
other app.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Simo Sorce]

On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
>  I mean, here's an example: let's say openssl is updated,
> which is
>  pulled
>  in by a ton of other things, for example the libc NSS LDAP module. The
>  libc NSS is used by at least half of all processes running on your
>  system,
>  and they all dlopen() the NSS module. So how do you now figure out
>  which
>  ones that are and how do you then figure out what the heck you need to
>  do to get them restarted?
>   
A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
is also deprecated on its own in favor of nss_ldapd and others.

B) Luckily we solved this case with SSSD, and this is exactly one of the
use cases we wanted to solve with it. The sssd client side that gets
loaded in processes has been made extremely simple and the protocol
fixed in stone exactly so that you can upgrade SSSD and it's
dependencies and even change sssd's configuration w/o having to restart
applications.

So I would remove the nsswitch problem, for the most part (we still have
some nsswitch things sssd does not handle like hostname resolution, but
we may take that over as well if really necessary.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Lennart Poettering]

On Thu, 24.01.13 21:15, Simo Sorce (simo(a)redhat.com) wrote:

>  On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
>  > I mean, here's an example: let's say openssl is updated, which is
>  > pulled
>  > in by a ton of other things, for example the libc NSS LDAP module. The
>  > libc NSS is used by at least half of all processes running on your
>  > system,
>  > and they all dlopen() the NSS module. So how do you now figure out
>  > which
>  > ones that are and how do you then figure out what the heck you need to
>  > do to get them restarted?
>  > 
>  A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
>  is also deprecated on its own in favor of nss_ldapd and others. 
Not part of libc? uh? no, of course not. It's still a module that is
loaded into libc via the libc NSS scheme, which is the point I am making
here...

And anyway you are missing the point here... this is just an
example. It's not particularly hard to come up with a different
example. Just think of some other NSS module, that uses some
library. Because of NSS its's loaded into half of our processes, all
they have to do is invoke gethostbyname() and the module and all
depending libaries are mapped in, and how would ever detect that?

>  B) Luckily we solved this case with SSSD, and this is exactly one of
> the
>  use cases we wanted to solve with it. The sssd client side that gets
>  loaded in processes has been made extremely simple and the protocol
>  fixed in stone exactly so that you can upgrade SSSD and it's
>  dependencies and even change sssd's configuration w/o having to restart
>  applications. 
Well you "fixed" a tiny facet of the issue. As it turns out however sssd
is not the only service we ship, is not the only package we ship, it's
not the only NSS module we ship, and update nss_sssd is still not
possible either...

>  So I would remove the nsswitch problem, for the most part (we still
> have
>  some nsswitch things sssd does not handle like hostname resolution, but
>  we may take that over as well if really necessary. 
Dude, sssd is not the only NSS module in the world, and NSS not the only
interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
pa modules, python loading any module, apache loading a module, gvfs
loading gvfs modules, ppp loading some module, ...

There's no way to determine those deps from the outside.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Simo Sorce]

On Fri, 2013-01-25 at 04:46 +0100, Lennart Poettering wrote:
>  On Thu, 24.01.13 21:15, Simo Sorce (simo(a)redhat.com) wrote:
>  
>  > On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
>  > > I mean, here's an example: let's say openssl is updated, which is
>  > > pulled
>  > > in by a ton of other things, for example the libc NSS LDAP module. The
>  > > libc NSS is used by at least half of all processes running on your
>  > > system,
>  > > and they all dlopen() the NSS module. So how do you now figure out
>  > > which
>  > > ones that are and how do you then figure out what the heck you need to
>  > > do to get them restarted?
>  > > 
>  > A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
>  > is also deprecated on its own in favor of nss_ldapd and others.
>  
>  Not part of libc? uh? no, of course not. It's still a module that is
>  loaded into libc via the libc NSS scheme, which is the point I am making
>  here...
>  
>  And anyway you are missing the point here... this is just an
>  example. It's not particularly hard to come up with a different
>  example. Just think of some other NSS module, that uses some
>  library. Because of NSS its's loaded into half of our processes, all
>  they have to do is invoke gethostbyname() and the module and all
>  depending libaries are mapped in, and how would ever detect that? 
cat /proc/$pid/maps

>  > B) Luckily we solved this case with SSSD, and this is exactly
> one of the
>  > use cases we wanted to solve with it. The sssd client side that gets
>  > loaded in processes has been made extremely simple and the protocol
>  > fixed in stone exactly so that you can upgrade SSSD and it's
>  > dependencies and even change sssd's configuration w/o having to restart
>  > applications.
>  
>  Well you "fixed" a tiny facet of the issue. As it turns out however sssd
>  is not the only service we ship, is not the only package we ship, it's
>  not the only NSS module we ship, and update nss_sssd is still not
>  possible either... 
And it is not necessary either, as I already explained.

>  > So I would remove the nsswitch problem, for the most part (we
> still have
>  > some nsswitch things sssd does not handle like hostname resolution, but
>  > we may take that over as well if really necessary.
>  
>  Dude, sssd is not the only NSS module in the world, and NSS not the only
>  interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
>  at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
>  pa modules, python loading any module, apache loading a module, gvfs
>  loading gvfs modules, ppp loading some module, ... 
Dude, nothing is perfect.

>  There's no way to determine those deps from the outside. 
Of course there is, for the currently running process.

But that is besides the point. yum upgrades, just like apt-get upgrades
work just fine in the very vast majority of times.

For daemons sensible rpms include condrestart statements.

If some user app misbehaves after the upgrade you just restart it. If
you know in advance which ones you *might* want to restart I will be
very glad if you give me a list as part of the final yum output, and I
will decide if I want to do that or not.

We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.

That said I think trying a distro-sync from a graphical session is just
a funny and instructive experience, I wouldn't recommend it as you'll
keep the pieces when your session blows up and brings with it your yum
upgrade, but it is certainly instructive :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Reindl Harald]

Am 25.01.2013 05:46, schrieb Simo Sorce:
>  That said I think trying a distro-sync from a graphical session is
> just
>  a funny and instructive experience, I wouldn't recommend it as you'll
>  keep the pieces when your session blows up and brings with it your yum
>  upgrade, but it is certainly instructive :) 
even this is no problem
screen is your friend

did it multiple times

well, there are times due the upgrade where things
behave strange, but webbrowsing is fine and even if
firefox gets unstable, just restart it

the point of distro-sync is to give advanced users
a upgrade option where they decide by theirself what
they are doing

[Matthew Garrett]

On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:

>  We are all grown up enough to decide for our own, just give the
>  information and let the admin take care of that. 
Well, that's the problem. Most of our users (including many of the 
professional sysadmins) are *not* able to make a fully informed choice 
about whether an online upgrade will ensure that they're no longer 
running any code with known security issues. That's not a criticism of 
them - it's just a much harder problem than almost everyone realises.

Nobody's suggesting making it impossible to use yum, but blessing it as 
a first-class distribution upgrade mechanism is a bad idea. There's far 
too many corner cases, and we can't justify the effort it'd take to fix 
all of them.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Simo Sorce]

On Fri, 2013-01-25 at 05:42 +0000, Matthew Garrett wrote:
>  On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
>  
>  > We are all grown up enough to decide for our own, just give the
>  > information and let the admin take care of that.
>  
>  Well, that's the problem. Most of our users (including many of the 
>  professional sysadmins) are *not* able to make a fully informed choice 
>  about whether an online upgrade will ensure that they're no longer 
>  running any code with known security issues. That's not a criticism of 
>  them - it's just a much harder problem than almost everyone realises.
>  
>  Nobody's suggesting making it impossible to use yum, but blessing it as 
>  a first-class distribution upgrade mechanism is a bad idea. There's far 
>  too many corner cases, and we can't justify the effort it'd take to fix 
>  all of them. 
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.

But I said my points, I won't argue anymore.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Lennart Poettering]

On Fri, 25.01.13 08:58, Simo Sorce (simo(a)redhat.com) wrote:

>  On Fri, 2013-01-25 at 05:42 +0000, Matthew Garrett wrote:
>  > On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
>  > 
>  > > We are all grown up enough to decide for our own, just give the
>  > > information and let the admin take care of that.
>  > 
>  > Well, that's the problem. Most of our users (including many of the 
>  > professional sysadmins) are *not* able to make a fully informed choice 
>  > about whether an online upgrade will ensure that they're no longer 
>  > running any code with known security issues. That's not a criticism of 
>  > them - it's just a much harder problem than almost everyone realises.
>  > 
>  > Nobody's suggesting making it impossible to use yum, but blessing it as 
>  > a first-class distribution upgrade mechanism is a bad idea. There's far 
>  > too many corner cases, and we can't justify the effort it'd take to fix 
>  > all of them.
>  
>  Nonsense, for a distribution upgrade you just recommend the admin to
>  reboot the system when done.
>  Everybody expects to reboot after a big distro-sync anyway as there is a
>  new kernel and basically new-everything. 
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Reindl Harald]

Am 25.01.2013 19:20, schrieb Lennart Poettering:
> > Nonsense, for a distribution upgrade you just recommend the admin
> to
> > reboot the system when done.
> > Everybody expects to reboot after a big distro-sync anyway as there is a
> > new kernel and basically new-everything.
>  
>  Ah, so you have to reboot anyway, so where is the difference between
>  your approach and proper offline updates then? Either way you have to
>  interrupt your work to reboot the machine. One just takes a slight bit
>  longer for rebooting... 
i had enough anaconda upgrades which failed to boot after that
by such things like missing initrd, missing rub-entry and so
on to have learend i want a upgrade where i can VERIFY all this
basic stuff, fix things, cleanup configurations, package-cleanup
and AFTER THAT i reboot the machine

guess - since i do it this way i survived calculated more
than 300 dist-upgares with yum and not a single one had
any problem coming up again, said that: from FC7 until F18
und the oldest setups are started with FC8 and now F18

[Simo Sorce]

On Fri, 2013-01-25 at 19:20 +0100, Lennart Poettering wrote:
>  On Fri, 25.01.13 08:58, Simo Sorce (simo(a)redhat.com) wrote:
>  
>  > On Fri, 2013-01-25 at 05:42 +0000, Matthew Garrett wrote:
>  > > On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
>  > > 
>  > > > We are all grown up enough to decide for our own, just give the
>  > > > information and let the admin take care of that.
>  > > 
>  > > Well, that's the problem. Most of our users (including many of the 
>  > > professional sysadmins) are *not* able to make a fully informed choice 
>  > > about whether an online upgrade will ensure that they're no longer 
>  > > running any code with known security issues. That's not a criticism of 
>  > > them - it's just a much harder problem than almost everyone realises.
>  > > 
>  > > Nobody's suggesting making it impossible to use yum, but blessing it as 
>  > > a first-class distribution upgrade mechanism is a bad idea. There's far 
>  > > too many corner cases, and we can't justify the effort it'd take to fix
>
>  > > all of them.
>  > 
>  > Nonsense, for a distribution upgrade you just recommend the admin to
>  > reboot the system when done.
>  > Everybody expects to reboot after a big distro-sync anyway as there is a
>  > new kernel and basically new-everything.
>  
>  Ah, so you have to reboot anyway, so where is the difference between
>  your approach and proper offline updates then? Either way you have to
>  interrupt your work to reboot the machine. One just takes a slight bit
>  longer for rebooting... 

A) One single reboot you do after not upfront.

If you are on a server logged in via ssh you can often keep doing some
work while most of the system is being updated and you can more easily
remote updates.

B) I will *not* trust an update system that cuts me out of my remote
server and make me *hope* it will come up later. If yum freaks out for
*whatever* reason I want to be there with an emergency shell open via
ssh to try to recover the system. Not have to call the colocation and
figure out what happened from possibly missing logs *if the system boots
at all*.

I've been saved more than once by a shell open during changes in the
configuration or upgrades, that is non-negotiable to me.

C) Not all updates require immediate reboot.
If I am updating the kernel and some minor package, I can as well decide
to reboot at the end of the day, rarely the update is so critical I have
to reboot NOW!

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Frank Ch. Eigler]

Simo Sorce <simo(a)redhat.com&gt; writes:

>  [...]  B) I will *not* trust an update system that cuts me out of my
>  remote server and make me *hope* it will come up later. If yum
>  freaks out for *whatever* reason I want to be there with an
>  emergency shell open [...]  I've been saved more than once by a
>  shell open during changes in the configuration or upgrades, that is
>  non-negotiable to me. [...] 
I agree that this capability is very important.

- FChE

[Matthew Garrett]

On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote:
>  Simo Sorce <simo(a)redhat.com&gt; writes:
>  
>  > [...]  B) I will *not* trust an update system that cuts me out of my
>  > remote server and make me *hope* it will come up later. If yum
>  > freaks out for *whatever* reason I want to be there with an
>  > emergency shell open [...]  I've been saved more than once by a
>  > shell open during changes in the configuration or upgrades, that is
>  > non-negotiable to me. [...]
>  
>  I agree that this capability is very important. 
Nobody has suggested removing it. It'll continue to work as well (or as 
badly, if you prefer) as it currently does.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Simo Sorce]

On Fri, 2013-01-25 at 21:57 +0000, Matthew Garrett wrote:
>  On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote:
>  > Simo Sorce <simo(a)redhat.com&gt; writes:
>  > 
>  > > [...]  B) I will *not* trust an update system that cuts me out of my
>  > > remote server and make me *hope* it will come up later. If yum
>  > > freaks out for *whatever* reason I want to be there with an
>  > > emergency shell open [...]  I've been saved more than once by a
>  > > shell open during changes in the configuration or upgrades, that is
>  > > non-negotiable to me. [...]
>  > 
>  > I agree that this capability is very important.
>  
>  Nobody has suggested removing it. It'll continue to work as well (or as 
>  badly, if you prefer) as it currently does. 
Unfortunately, lately I have the impression you need to state even
obvious things very clearly lest they are removed 'to improve' the
system.

So, just making it clear.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Mike Pinkerton]

On 25 Jan 2013, at 14:23, Simo Sorce wrote:

> > Ah, so you have to reboot anyway, so where is the difference
> between
> > your approach and proper offline updates then? Either way you have to
> > interrupt your work to reboot the machine. One just takes a slight  
> > bit
> > longer for rebooting...
>
>
>  A) One single reboot you do after not upfront.
>
>  If you are on a server logged in via ssh you can often keep doing some
>  work while most of the system is being updated and you can more easily
>  remote updates.
>
>  B) I will *not* trust an update system that cuts me out of my remote
>  server and make me *hope* it will come up later. If yum freaks out for
>  *whatever* reason I want to be there with an emergency shell open via
>  ssh to try to recover the system. Not have to call the colocation and
>  figure out what happened from possibly missing logs *if the system  
>  boots
>  at all*.
>
>  I've been saved more than once by a shell open during changes in the
>  configuration or upgrades, that is non-negotiable to me. 

I do the same for the same reasons.


>  C) Not all updates require immediate reboot.
>  If I am updating the kernel and some minor package, I can as well  
>  decide
>  to reboot at the end of the day, rarely the update is so critical I  
>  have
>  to reboot NOW! 

For normal updates, yes.  But I would not start an upgrade from one  
Fedora release to another at an "inconvenient time" and then wait to  
reboot hours later.

In this discussion of whether "yum upgrade" would be enhanced  
alongside FedUp, I had assumed that FedUp would only be used for  
upgrading from one Fedora release to the next, not for regular  
software updates.  Is that assumption wrong?

-- 
Mike

[Michael Scherer]

Le vendredi 25 janvier 2013 à 19:20 +0100, Lennart Poettering a écrit :

>  Ah, so you have to reboot anyway, so where is the difference between
>  your approach and proper offline updates then? Either way you have to
>  interrupt your work to reboot the machine. One just takes a slight bit
>  longer for rebooting... 
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives, that's IMHO a pretty significant downtime.

-- 
Michael Scherer

[Matthew Garrett]

On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote:

>  Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
>  already did version upgrade taking 6 to 8h due to slow internet or slow
>  hard drives, that's IMHO a pretty significant downtime. 
fedup does all network activity before reboot, so presumably you're 
talking about some upgrade system other than the currently supported 
one?

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Michael Scherer]

Le samedi 26 janvier 2013 à 06:21 +0000, Matthew Garrett a écrit :
>  On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote:
>  
>  > Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
>  > already did version upgrade taking 6 to 8h due to slow internet or slow
>  > hard drives, that's IMHO a pretty significant downtime.
>  
>  fedup does all network activity before reboot, so presumably you're 
>  talking about some upgrade system other than the currently supported 
>  one? 
You are right, the 6 to 8h is indeed unrelated, this was on a very old
computer, not using fedup, and this was for the download + install part,
just to give a order of magnitude ( heck, i should really refrain from
using evo during the night )

And for the 2 to 3h, I didn't look at the details, it was in the LUG
meeting and the time between I gave the instruction and the time the
person came back to me. While I think the exact time is not important,
let me do a test to have more precise data, so my bad memories do not
muddle the discussion ( as people around me say "depend, maybe 1h, maybe
more" when asked about fedup ).

-- 
Michael Scherer

[Kevin Kofler]

Lennart Poettering wrote:
>  Ah, so you have to reboot anyway, so where is the difference between
>  your approach and proper offline updates then? Either way you have to
>  interrupt your work to reboot the machine. One just takes a slight bit
>  longer for rebooting... 
That yum is tested every day and known to work, whereas FedUp is 
experimental and incomplete (no signature checking) code.

        Kevin Kofler

[Chris Murphy]

On Jan 24, 2013, at 10:42 PM, Matthew Garrett <mjg59(a)srcf.ucam.org&gt; wrote:
>  
>  Well, that's the problem. Most of our users (including many of the 
>  professional sysadmins) are *not* able to make a fully informed choice 
>  about whether an online upgrade will ensure that they're no longer 
>  running any code with known security issues. That's not a criticism of 
>  them - it's just a much harder problem than almost everyone realises. 
My Scottish co-author and dear friend referred to such cases as "giving users razor
blades, and telling them to go play on the freeway."

After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the
upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC
Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10
minutes). 

Meanwhile, a yum upgrade involves a transition from download to upgrade without
notification, concomitant with the potential for arbitrary and untimely implosion that
could hose the entire upgrade. And this is on a supposedly important computer that
can't be down for 2 hours? Umm? I really don't understand this thread.

Chris Murphy

[Mike Pinkerton]

On 26 Jan 2013, at 12:11, Chris Murphy wrote:

>  After 1/2 dozen fedup upgrades during testing, on average the  
>  downtime portion of the upgrade was between 25 and 40 minutes. On a  
>  five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust  
>  drive (the new computer with SSD did the fedup upgrade in less than  
>  10 minutes).
>
>  Meanwhile, a yum upgrade involves a transition from download to  
>  upgrade without notification, concomitant with the potential for  
>  arbitrary and untimely implosion that could hose the entire  
>  upgrade. And this is on a supposedly important computer that can't  
>  be down for 2 hours? Umm? I really don't understand this thread. 

Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16.

On a remote yum upgrade, you can follow yum's progress -- see if it  
hangs, see any failure warnings, etc., fix what you can after it  
finishes -- then hold your breath when you reboot.  If the box isn't  
back online within 2 minutes, you know you have a major problem and  
contact the data center immediately.

If a fedup upgrade can go offline for a lengthy, but uncertain,  
amount of time, then the lack of feedback is worrying.  You can't  
hold your breath for 25 minutes, you don't know when to conclude that  
you have a serious problem that will require help from the data  
center staff, and you don't have any idea where the process went off- 
track.

If you could SSH into fedup during its "offline" period and get real  
time feedback about what it is doing and any errors it encounters,  
and perhaps the ability to fix any problems when it finishes but  
before it attempts to reboot, then it would be less scary for remote  
upgrades.

-- 
Mike

[Chris Murphy]

On Jan 26, 2013, at 10:45 AM, Mike Pinkerton <pselists(a)mindspring.com&gt; wrote:
>  
>  If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the
> lack of feedback is worrying.  You can't hold your breath for 25 minutes, you
> don't know when to conclude that you have a serious problem that will require help
> from the data center staff, and you don't have any idea where the process went
> off-track. 
I think the lack of feedback with fedup is a known weak area that needs improvement. I
found that by deleting 'quiet rhgb' and adding one of the debug options to the
fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a:

journalcti --follow

And I get live updates throughout the process. I don't recall "hang" without
some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps
are available, I think at least one of them is.

>  If you could SSH into fedup during its "offline" period and
> get real time feedback about what it is doing and any errors it encounters, and perhaps
> the ability to fix any problems when it finishes but before it attempts to reboot, then it
> would be less scary for remote upgrades. 
I haven't tried 'systemctl start sshd' during the upgrade to see what happens;
it's probably not totally benign to do this, since ssh will be upgraded, but it seems
a lot safer, vastly so, than a live yum update while a server is running.

I don't know any company that allows major upgrades without user processes being
required to quit. Apple and Microsoft both download and stage their upgrades, no user
processes allowed, a partially upgraded system reboots, completes the primary upgrade
tasks before user sessions are allowed again (and Windows might have one more reboot, I
forget).

Once upon a time, Apple allows user session to stay live during the installation of minor
system software updates. They don't even do this anymore. Apparently it was so fraught
with peril. So now, the download occurs in the background during the user session, and you
have the option to being the install which also requires a restart. If you agree,
you're logged out, user processes quit, the update begins, the system reboots.

I just don't see how it's best practices to be doing updates on live processes.
This seems sorta like a game to find out just how much one can cheat the upgrade process
before the ship will in fact sink.

Chris Murphy

[Mike Pinkerton]

On 26 Jan 2013, at 13:09, Chris Murphy wrote:

>  On Jan 26, 2013, at 10:45 AM, Mike Pinkerton  
>  <pselists(a)mindspring.com&gt; wrote:
> >
> > If a fedup upgrade can go offline for a lengthy, but uncertain,  
> > amount of time, then the lack of feedback is worrying.  You can't  
> > hold your breath for 25 minutes, you don't know when to conclude  
> > that you have a serious problem that will require help from the  
> > data center staff, and you don't have any idea where the process  
> > went off-track.
>
>  I think the lack of feedback with fedup is a known weak area that  
>  needs improvement. I found that by deleting 'quiet rhgb' and adding  
>  one of the debug options to the fedup kenel at reboot time, I can  
>  get to a shell during the upgrade, and issue a:
>
>  journalcti --follow
>
>  And I get live updates throughout the process. I don't recall  
>  "hang" without some sort of feedback for more than maybe 5 minutes.  
>  I forget off hand if top and/or ps are available, I think at least  
>  one of them is. 

I can see how this would help when sitting in front of the box, but  
when you're hundreds or thousands of miles away, it isn't really an  
option.


> > If you could SSH into fedup during its "offline" period
> and get  
> > real time feedback about what it is doing and any errors it  
> > encounters, and perhaps the ability to fix any problems when it  
> > finishes but before it attempts to reboot, then it would be less  
> > scary for remote upgrades.
>
>  I haven't tried 'systemctl start sshd' during the upgrade to see  
>  what happens; it's probably not totally benign to do this, since  
>  ssh will be upgraded, but it seems a lot safer, vastly so, than a  
>  live yum update while a server is running. 

Would it work for the network and sshd to be run from the initramfs  
rather than the file system that is being updated?

It would be nice if one could start fedup with a flag that would tell  
it to start the network and sshd upon reboot, and enable feedback to  
a remote user.  That would make the process a lot less worrisome.


-- 
Mike

[Michael Scherer]

Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit :
>  On 26 Jan 2013, at 13:09, Chris Murphy wrote:
>  
>  > On Jan 26, 2013, at 10:45 AM, Mike Pinkerton  
>  > <pselists(a)mindspring.com&gt; wrote:
>  >>
>  >> If you could SSH into fedup during its "offline" period and get  
>  >> real time feedback about what it is doing and any errors it  
>  >> encounters, and perhaps the ability to fix any problems when it  
>  >> finishes but before it attempts to reboot, then it would be less  
>  >> scary for remote upgrades.
>  >
>  > I haven't tried 'systemctl start sshd' during the upgrade to see  
>  > what happens; it's probably not totally benign to do this, since  
>  > ssh will be upgraded, but it seems a lot safer, vastly so, than a  
>  > live yum update while a server is running.
>  
>  
>  Would it work for the network and sshd to be run from the initramfs  
>  rather than the file system that is being updated? 
Then you need to have the network configuration, etc. This can be done,
but for now, the feature is not in dracut, see this bug for a similar
request for encrypted root :
https://bugzilla.redhat.com/show_bug.cgi?id=524727

-- 
Michael Scherer

[Mike Pinkerton]

On 26 Jan 2013, at 15:28, Michael Scherer wrote:

>  Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit :
> > On 26 Jan 2013, at 13:09, Chris Murphy wrote:
> >
> >> On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
> >> <pselists(a)mindspring.com&gt; wrote:
> >>>
> >>> If you could SSH into fedup during its "offline" period and get
> >>> real time feedback about what it is doing and any errors it
> >>> encounters, and perhaps the ability to fix any problems when it
> >>> finishes but before it attempts to reboot, then it would be less
> >>> scary for remote upgrades.
> >>
> >> I haven't tried 'systemctl start sshd' during the upgrade to see
> >> what happens; it's probably not totally benign to do this, since
> >> ssh will be upgraded, but it seems a lot safer, vastly so, than a
> >> live yum update while a server is running.
> >
> >
> > Would it work for the network and sshd to be run from the initramfs
> > rather than the file system that is being updated?
>
>  Then you need to have the network configuration, etc. This can be  
>  done,
>  but for now, the feature is not in dracut, see this bug for a similar
>  request for encrypted root :
>  https://bugzilla.redhat.com/show_bug.cgi?id=524727 

That bug looks like a superset of what would be needed to run the  
network and sshd from the initramfs.

As for network configuration, in the past (I haven't tried it with  
F18's new Anaconda), one could do a VNC-enabled install by passing a  
minimal network configuration (interface and IP address), as well as  
a VNC password, on the kernel line.  Perhaps for a ssh-enabled fedup,  
one could do something similar, passing an interface and IP address  
to fedup, possibly as well as a one-time use ssh password and a  
"permitted" remote IP address block from which one could connect.   
How those persist across the reboot -- whether fedup writes those to  
the kernel line in grub.conf as one would do with a remote VNC  
install, or they are written into the initramfs -- would be a question.

-- 
Mike

[Gerd Hoffmann]

  Hi,

>  If a fedup upgrade can go offline for a lengthy, but uncertain,
> amount
>  of time, then the lack of feedback is worrying.  You can't hold your
>  breath for 25 minutes, you don't know when to conclude that you have a
>  serious problem that will require help from the data center staff, and
>  you don't have any idea where the process went off-track. 
I actually like fedup, and I guess I'll go stop using yum for upgrades
if I can use fedup instead.

I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up
multiple times and settled on using yum instead.

But fedup is different.  Even though it is still quite young I actually
trust it to get things right.  It fetches all packages, then does a
transaction check and if that fails it says so and allows you to fixup
stuff before actually kicking the upgrade.  Remove orphaned packages
causing dep issues, cleanup disk so filesystems have enough free space
to run the transaction, whatever is needed.

That is very simliar to how you handle issues when upgrading using yum.

Once everything is settled and fedup says "reboot to upgrade" you can be
pretty sure that it will work fine.

cheers,
  Gerd

[Adam Williamson]

On Mon, 2013-01-28 at 14:01 +0100, Gerd Hoffmann wrote:
>    Hi,
>  
>  > If a fedup upgrade can go offline for a lengthy, but uncertain, amount
>  > of time, then the lack of feedback is worrying.  You can't hold your
>  > breath for 25 minutes, you don't know when to conclude that you have a
>  > serious problem that will require help from the data center staff, and
>  > you don't have any idea where the process went off-track.
>  
>  I actually like fedup, and I guess I'll go stop using yum for upgrades
>  if I can use fedup instead.
>  
>  I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up
>  multiple times and settled on using yum instead.
>  
>  But fedup is different.  Even though it is still quite young I actually
>  trust it to get things right.  It fetches all packages, then does a
>  transaction check and if that fails it says so and allows you to fixup
>  stuff before actually kicking the upgrade.  Remove orphaned packages
>  causing dep issues, cleanup disk so filesystems have enough free space
>  to run the transaction, whatever is needed.
>  
>  That is very simliar to how you handle issues when upgrading using yum.
>  
>  Once everything is settled and fedup says "reboot to upgrade" you can be
>  pretty sure that it will work fine. 
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure of what's going to happen
during a given fedup transaction, you should also check what scripts are
going to get fired as part of the upgrade. In F18 I'm not sure there are
any, but this is the kind of mechanism we would use, fr'instance, to
switch the default bootloader as part of an upgrade in future, if we
decided we wanted to do that again. The kind of stuff that can't be done
in %pre/%post etc.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Miroslav Suchý]

On 01/29/2013 12:59 AM, Adam Williamson wrote:
>  Well, the other thing fedup does - and the other reason it's
> necessary
>  compared to a simple online yum upgrade - is provide a mechanism for
>  pretty much any package to hook in pretty much any action to be
>  performed as part of the upgrade. To be sure of what's going to happen
>  during a given fedup transaction, you should also check what scripts are
>  going to get fired as part of the upgrade. In F18 I'm not sure there are
>  any, but this is the kind of mechanism we would use, fr'instance, to
>  switch the default bootloader as part of an upgrade in future, if we
>  decided we wanted to do that again. The kind of stuff that can't be done
>  in %pre/%post etc. 
Is this documented somewhere? I would like to read more about this feature.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Adam Williamson]

On Mon, 2013-02-04 at 18:11 +0100, Miroslav Suchý wrote:
>  On 01/29/2013 12:59 AM, Adam Williamson wrote:
>  > Well, the other thing fedup does - and the other reason it's necessary
>  > compared to a simple online yum upgrade - is provide a mechanism for
>  > pretty much any package to hook in pretty much any action to be
>  > performed as part of the upgrade. To be sure of what's going to happen
>  > during a given fedup transaction, you should also check what scripts are
>  > going to get fired as part of the upgrade. In F18 I'm not sure there are
>  > any, but this is the kind of mechanism we would use, fr'instance, to
>  > switch the default bootloader as part of an upgrade in future, if we
>  > decided we wanted to do that again. The kind of stuff that can't be done
>  > in %pre/%post etc.
>  
>  Is this documented somewhere? I would like to read more about this feature. 
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda.
That's the best that I know of.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Miroslav Suchý]

On 02/04/2013 10:29 PM, Adam Williamson wrote:
> https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/  ... kinda.
> That's the best that I know of. 
It lacks in details how I can put hook in upgrade.pre and upgrade.post. 
What is the best practise here?

It would be nice if you can enhance:
http://fedoraproject.org/wiki/Packaging:Guidelines
with example snippets and general guidance how packager can create such 
hook.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Adam Williamson]

On Tue, 2013-02-05 at 08:54 +0100, Miroslav Suchý wrote:
>  On 02/04/2013 10:29 PM, Adam Williamson wrote:
>  > https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/  ... kinda.
> That's the best that I know of.
>  
>  It lacks in details how I can put hook in upgrade.pre and upgrade.post. 
>  What is the best practise here?
>  
>  It would be nice if you can enhance:
>  http://fedoraproject.org/wiki/Packaging:Guidelines
>  with example snippets and general guidance how packager can create such 
>  hook. 
I agree that would be nice, but I am not actually the author of the
feature or a user of it, so I don't have the expertise on tap. :) Will
is the one currently best-placed to do so. So far as I'm aware these are
simply dracut hooks so dracut docs would apply, but I'm not sure.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Nicolas Mailhot]

Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit :
>   Applications have deps on all kinds of
>  data in /usr/lib, not just shared libraries. Such as locale data, icons,
>  fonts, artwork, documentation. 
BTW Firefox seems to be the only application that goes bonkers when fonts
are updated while it's running, so it looks more like a bug in Firefox's
text rendering than a general problem to me

-- 
Nicolas Mailhot

[Reindl Harald]

Am 25.01.2013 18:00, schrieb Nicolas Mailhot:
>  
>  Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit :
> >  Applications have deps on all kinds of
> > data in /usr/lib, not just shared libraries. Such as locale data, icons,
> > fonts, artwork, documentation.
>  
>  BTW Firefox seems to be the only application that goes bonkers when fonts
>  are updated while it's running, so it looks more like a bug in Firefox's
>  text rendering than a general problem to me 
and on the other hand i had longer time ago troubles with
my systemdisk suddenly disappear until hard power off and
more than one time i used firefox for half an hour because
it had anything in the memory and freezed only if it should
display a dialog with icons not loaded before

proven by /var/log/ on a different disk with errors in a
"tail -f" while all aplications worked for minutes and
even VMware machines could be CLEAN powered off via SSH
from a notebook as long they were on a different physical
drive

so no - it's not that bad doing updates while things running

[Przemek Klosowski]

On 01/24/2013 06:12 PM, Lennart Poettering wrote:
>  If you restart any of those you bring down the entire machine
> basically,
>  or bring down at least the bits you really want to avoid, i.e. the
>  user's sessions...
>
>  Then all code that runs that is not a system service is difficult to
>  restart from a system script. How do you plan to restart Evolution or
>  Firefox, or Gimp? 
...
>  Of course, you could tell the user as last step of your script to
>  "please reboot now", but if you do that your update isn't
> "online"
>  anymore, but is awfully close to real offline upgrades, except that
>  during the upgrade period you have a ton of processes around that might
>  be seriously confused by not being able to find their own resources
>  anymore or in wrong versions... 
This is a pessimistic view but I think it's not as intractable.

There are two separate aspects to it: discovery what needs to be 
restarted, and the actual process of restarting. The discovery is almost 
there: we know the resources (libs, files, etc) that were replaced, so 
it's a matter of walking the list of running processes and checking if 
they depend on those resources. I can see how transient I/O, including 
dlopen() could be tricky, but I don't think it's fundamentally 
impossible---at worst, it'd be implementing some sort of 
/proc/1234/history-of-opened-fd mechanism.

That leaves the restarting: again it seems to me that is not as hopeless 
as you make it sound, either: kernel is hardest but even there people 
are working on ksplice. Many services are designed to be restarted, like 
DHCPD which doesn't even have an online reload but has to be bounced if 
the DHCP data file changes.

Regular process restart is of course application dependent,  but e.g. 
Firefox actually restarts relatively graciously: I just killed mine and 
the new instance reopened all my tabs (a pleasant surprise--I expected 
the Restore Session ("Well this is embarrassing") window I was used to). 
Maybe there is a couple of classes that the restart falls into:

- no problems restarting anytime

- availability problems but no data loss on restart (easy restart but 
maybe needs user confirmation)

- some out-of-process support needed (file rotation/cleanup, etc)

- user intervention required (saving files, etc).


I believe that seamless upgrades are an attractive goal. I am not 
arguing for infinite upgrades---only a fresh install can guarantee 
getting all new technologies that one wouldn't get through upgrades 
because they may not even existed at the original installation. My point 
is that the reinstall decision should be in principle driven by the 
user, not by the OS release schedule.

[Lennart Poettering]

On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosowski(a)nist.gov) wrote:

>  On 01/24/2013 06:12 PM, Lennart Poettering wrote:
>  >If you restart any of those you bring down the entire machine basically,
>  >or bring down at least the bits you really want to avoid, i.e. the
>  >user's sessions...
>  >
>  >Then all code that runs that is not a system service is difficult to
>  >restart from a system script. How do you plan to restart Evolution or
>  >Firefox, or Gimp?
>  ...
>  >Of course, you could tell the user as last step of your script to
>  >"please reboot now", but if you do that your update isn't
> "online"
>  >anymore, but is awfully close to real offline upgrades, except that
>  >during the upgrade period you have a ton of processes around that might
>  >be seriously confused by not being able to find their own resources
>  >anymore or in wrong versions...
>  
>  This is a pessimistic view but I think it's not as intractable.
>  
>  There are two separate aspects to it: discovery what needs to be
>  restarted, and the actual process of restarting. The discovery is
>  almost there: we know the resources (libs, files, etc) that were
>  replaced, so it's a matter of walking the list of running processes
>  and checking if they depend on those resources. I can see how
>  transient I/O, including dlopen() could be tricky, but I don't think
>  it's fundamentally impossible---at worst, it'd be implementing some
>  sort of /proc/1234/history-of-opened-fd mechanism. 
That doesn't work. Let's say my app needs to display a certain icon in
some dialog. The next version of that app doesn't need that icon
anymore, so on upgrade the icon is deleted. At the same time the user is
still running that app, and then enters the dialog. The app now looks
for the icon, and doesn't find it. Bang.

There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.

The icon thing is just one example, you can now extrapolate from that...

>  That leaves the restarting: again it seems to me that is not as
>  hopeless as you make it sound, either: kernel is hardest but even
>  there people are working on ksplice. Many services are designed to
>  be restarted, like DHCPD which doesn't even have an online reload
>  but has to be bounced if the DHCP data file changes. 
"kernel is hardest"? Yuck. Kernel is not feasible. And much of the rest
isn't either.

I'll wait your patches for the kernel to allow seamless upgrades of the
kernel without reboots.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Bill Nottingham]

Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  I'll wait your patches for the kernel to allow seamless upgrades
> of the
>  kernel without reboots. 
Sure, just have a ksplice server that generates splices for each new kernel
build relative to the previous one, and your upgrade process downloads all of
the series of splices and applies them. Voila!

The ksplice series from 2.6.18 to 3.7 will be loads of fun.

Bill

(NOTE: THIS IS NOT A SERIOUS IDEA.)

[Przemek Klosowski]

My point is that it'd be nice to improve the upgrades. I love 
upgrades---I love the shiny new toys and I hate them for the disruption 
they always bring, at someone else's schedule. As you say, there are 
good reasons why it's what it is now, and maybe you're right that it 
can't be significantly changed. I am just trying to think what COULD be 
done, because such improvements would benefit regular updates ('yum 
update') as well.

On 01/25/2013 01:27 PM, Lennart Poettering wrote:
>  There is no sane way to determine all these dependencies, because many
>  of them are never explicit, and only temporary in nature. Well written
>  apps load a lot of resources lazily. That has the side effect that you
>  can never know those deps, until they are actually needed. 
You are right, can't be solved with the simplistic approach I 
discussed--it would have to be more complex than that.  This of course 
is true of any upgrade, even the routine 'yum update', so improving this 
situation is desirable even if one disagrees about distribution upgrades.

We know what resources we had and what we replaced them with. Perhaps we 
could at least tag the running processes that will need restarting and 
notify the users/administrators.

>  "kernel is hardest"? Yuck. Kernel is not feasible. And much
> of the rest
>  isn't either. 
So kernel is out. DHCP is definitely possible. The others are somewhere 
in between. My point again is that I think the upgrades are a sore point 
for the users and it'd be nice to improve the process. If indeed this 
can't be done properly, then the second best is a fall-back of having 
the infrastructure to do it anyway and notify the user about which 
pieces need special attention.

[Bruno Wolff III]

On Fri, Jan 25, 2013 at 14:22:44 -0500,
   Przemek Klosowski <przemek.klosowski(a)nist.gov&gt; wrote:
> My point is that it'd be nice to improve the upgrades. I love 
> upgrades---I love the shiny new toys and I hate them for the 
> disruption they always bring, at someone else's schedule. As you say, 
> there are good reasons why it's what it is now, and maybe you're 
> right that it can't be significantly changed. I am just trying to 
> think what COULD be done, because such improvements would benefit 
> regular updates ('yum update') as well. 
Sure any help getting stuff properly obsoleted and the like is good. I don't 
think we really want it to be a feaure though.

[Pavel Alexeev]

25.01.2013 22:27, Lennart Poettering пишет:
>  On Fri, 25.01.13 13:02, Przemek Klosowski
> (przemek.klosowski(a)nist.gov) wrote:
>
> > On 01/24/2013 06:12 PM, Lennart Poettering wrote:
> >> If you restart any of those you bring down the entire machine basically,
> >> or bring down at least the bits you really want to avoid, i.e. the
> >> user's sessions...
> >>
> >> Then all code that runs that is not a system service is difficult to
> >> restart from a system script. How do you plan to restart Evolution or
> >> Firefox, or Gimp?
> > ...
> >> Of course, you could tell the user as last step of your script to
> >> "please reboot now", but if you do that your update isn't
> "online"
> >> anymore, but is awfully close to real offline upgrades, except that
> >> during the upgrade period you have a ton of processes around that might
> >> be seriously confused by not being able to find their own resources
> >> anymore or in wrong versions...
> > This is a pessimistic view but I think it's not as intractable.
> >
> > There are two separate aspects to it: discovery what needs to be
> > restarted, and the actual process of restarting. The discovery is
> > almost there: we know the resources (libs, files, etc) that were
> > replaced, so it's a matter of walking the list of running processes
> > and checking if they depend on those resources. I can see how
> > transient I/O, including dlopen() could be tricky, but I don't think
> > it's fundamentally impossible---at worst, it'd be implementing some
> > sort of /proc/1234/history-of-opened-fd mechanism.
>  That doesn't work. Let's say my app needs to display a certain icon in
>  some dialog. The next version of that app doesn't need that icon
>  anymore, so on upgrade the icon is deleted. At the same time the user is
>  still running that app, and then enters the dialog. The app now looks
>  for the icon, and doesn't find it. Bang.
>
>  There is no sane way to determine all these dependencies, because many
>  of them are never explicit, and only temporary in nature. Well written
>  apps load a lot of resources lazily. That has the side effect that you
>  can never know those deps, until they are actually needed.
>
>  The icon thing is just one example, you can now extrapolate from that... 
Sorry but
how such use case different from simple firefox update in 
current release when it happened parallel with browsing?? It may also 
lead to that unpredictable behavior. Off course you will say it 
shouldn't be major release in stable Fedora. And off course it is true. 
But anyone can't guaranty what even change or delete 1 file do not lead 
to unstable app. So for that cases graphical application similar to 
PackageKit suggests user reboot (and may suggest only reload certain 
apps) with list of apps, based on maintainers expectation from ("suggest 
reboot" in bodhi update system). I hope you do not suggest force reload 
such apps for user of force always offline update for that thinks. In 
that point of view "online" distro update differs only by amount of 
updated packages which "suggest reboot" for user. And I may himself plan 
reboot when I want...
-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact 
with me use jabber: Hubbitus(a)jabber.ru

[Miroslav Suchý]

On 01/25/2013 12:12 AM, Lennart Poettering wrote:
>  So, you can ignore all of that, but then you have to think about
> what
>  you actually accomplished by your upgrade? You updated a couple of
>  libraries, and maybe managed to restart a few processes using them, but
>  for the rest of them the vulnerable openssl version is still in memory,
>  still actively used, even though your update script exited successfully
>  leaving the user under the impression that all was good now and that
>  after he made this upgrade his machine was not vulnerable anymore. 
And how this differ from
   yum upgrade
which I'm doing every day/week?

Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade 
and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora 
release.

So we are ignoring this behaviour in middle of release, but it is very 
serious problem between releases?

-- 
Miroslav Suchy
Red Hat Systems Management Engineering

[Reindl Harald]

Am 04.02.2013 18:35, schrieb Miroslav Suchý:
>  On 01/25/2013 12:12 AM, Lennart Poettering wrote:
> > So, you can ignore all of that, but then you have to think about what
> > you actually accomplished by your upgrade? You updated a couple of
> > libraries, and maybe managed to restart a few processes using them, but
> > for the rest of them the vulnerable openssl version is still in memory,
> > still actively used, even though your update script exited successfully
> > leaving the user under the impression that all was good now and that
> > after he made this upgrade his machine was not vulnerable anymore.
>  
>  And how this differ from
>    yum upgrade
>  which I'm doing every day/week?
>  
>  Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not
> rebooted from day zero.
>  I have exactly the same problem as during yum upgrade to next Fedora release.
>  
>  So we are ignoring this behaviour in middle of release, but it is very serious problem
> between releases? 
oh even if people like i did some hundret dist-upgrades over the
years it was us told that linux has to go the windows way:

http://fedoraproject.org/wiki/Features/OfflineSystemUpdates

a few years ago you could make a dist-upgrade and even httpd
and fileservers like "netatalk" were running in the old
version until reboot, did it, was there

then fedora introduced the restart-service-snippets in
every SPEC file, after that came Packagekit and after
systemd now all the things worked over decades are
suddenly not possible in a clean way - i do not buy
that the development goes in the right direction at all

[Kevin Kofler]

Reindl Harald wrote:
>  oh even if people like i did some hundret dist-upgrades over the
>  years it was us told that linux has to go the windows way:
>  
>  http://fedoraproject.org/wiki/Features/OfflineSystemUpdates 
Yeah, this is a really insane "feature"!

Let me assure you that this "feature" is only currently implemented in 
gnome-packagekit. The command-line tools will probably NEVER implement this. 
As for Apper, I can assure you that:
* this "feature" is not currently implemented in Apper,
* Apper's upstream author plans to support it in the future, but make it 
optional, and
* KDE SIG has strong reservations about the usefulness and desirability of 
this "feature" and it will likely end up disabled by default in Fedora if 
implemented.

        Kevin Kofler

[drago01]

On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Reindl Harald wrote:
> > oh even if people like i did some hundret dist-upgrades over the
> > years it was us told that linux has to go the windows way:
> >
> > http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
>
>  Yeah, this is a really insane "feature"!
>
>  Let me assure you that this "feature" is only currently implemented in
>  gnome-packagekit. The command-line tools will probably NEVER implement this.
>  As for Apper, I can assure you that:
>  * this "feature" is not currently implemented in Apper,
>  * Apper's upstream author plans to support it in the future, but make it
>  optional, and
>  * KDE SIG has strong reservations about the usefulness and desirability of
>  this "feature" and it will likely end up disabled by default in Fedora if
>  implemented. 
Yes become ignoring problems by pretending that they do not exist is
the way to go ....

[Reindl Harald]

Am 09.02.2013 15:52, schrieb drago01:
>  On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > Reindl Harald wrote:
> >> oh even if people like i did some hundret dist-upgrades over the
> >> years it was us told that linux has to go the windows way:
> >>
> >> http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
> >
> > Yeah, this is a really insane "feature"!
> >
> > Let me assure you that this "feature" is only currently implemented in
> > gnome-packagekit. The command-line tools will probably NEVER implement this.
> > As for Apper, I can assure you that:
> > * this "feature" is not currently implemented in Apper,
> > * Apper's upstream author plans to support it in the future, but make it
> > optional, and
> > * KDE SIG has strong reservations about the usefulness and desirability of
> > this "feature" and it will likely end up disabled by default in Fedora if
> > implemented.
>  
>  Yes become ignoring problems by pretending that they do not exist is
>  the way to go .... 
why preklink not banned which also touches probably running
binaries, but hey in this case it is OK because it was a
fedora feature years ago and there must be good

which problems?
where were they over decades?
who did introduce them recently?
why this bugs are not fixed?

[Rahul Sundaram]

Hi


On Mon, Feb 4, 2013 at 12:35 PM, Miroslav Suchý wrote:

>  Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade
>  and not rebooted from day zero.
>  I have exactly the same problem as during yum upgrade to next Fedora
>  release.
>
>  So we are ignoring this behaviour in middle of release, but it is very
>  serious problem between releases?
>  
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

Rahul

[Kevin Kofler]

Lennart Poettering wrote:
>  The thing is that doing on-line updates only works for stuff you can
>  restart, and that doesn't mind that things are not atomically
>  updated. However, much (most?) of our code isn't like that. Anybody who
>  tried to update the Firefox RPM while it is running knows that this
>  doesn't end well, and you frequently have to manually kill firefox to
>  get it back into a usual state. 
Strawman alert!

Who ever said that this feature is about online upgrades? Even the 
"Upgrading Fedora using yum" wiki page clearly says that upgrades should be 
done in runlevel 3 (multi-user.target), not in runlevel 5 
(graphical.target).

The point of using yum to upgrade is not to do it in a running user session, 
but to use the same frequently-tested code paths as for normal updates 
rather than a special distro-upgrade-only one where half of the 
functionality has to be reimplemented differently (see e.g. FedUp not 
supporting something as basic as signature checks; why do we even bother 
signing our packages if we're happy to deliver an "official" and 
"recommended" upgrade method which won't even bother checking them?).

        Kevin Kofler

[Josh Boyer]

On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Features/FedoraUpgrade =
>  https://fedoraproject.org/wiki/Features/FedoraUpgrade
>
>  Feature owner(s):  Miroslav Suchý <msuchy(a)redhat.com&gt;
>
>  Upgrade Fedora to next version using yum upgrade. 
I see no reason to make this an officially supported method to upgrade
Fedora.  The QA team is already swamped with work just getting the new
install tests done, and now fedup tests.  Having a third way of getting
a Fedora release onto a machine is going to expand the testing matrix
even more.  This isn't replacing something, it's just creating more
work.

Yum upgrade has always been possible but not supported.  Seems it can
stay that way.

josh

[Bruno Wolff III]

>  
>  If this method will be tested by FedoraQA, then I believe this upgrade method 
>  can be safely recommended to user.  
The feature owners of this need to do the testing and prodding, not QA. The 
way this feature is written, it seems to imply that QA is supposed to 
implement this feature.

Note that this doesn't fix problems caused by dropped packages, that block 
other packages from being updated. One possiblity here would be to create 
a special package that obsoletes all of the dropped packages from the 
last release (or two depending on how far back you want to yum update from).

There are going to be some releases where you need to do things outside of 
yum to upgrade. I don't know that we want to advertise this as a feature 
when it can't really be supported from release to release. However, a group 
of people who wanted to report bugs for missing obsoletes and the like 
would be appreciated.

Remove retired packages

[Vít Ondruch]

Dne 23.1.2013 21:04, Bruno Wolff III napsal(a):
>  One possiblity here would be to create a special package that 
>  obsoletes all of the dropped packages from the last release (or two 
>  depending on how far back you want to yum update from). 
Actually, this is cool idea IMO. Why this package does not exist yet? 
Rel-engs has to have list of blocked packages already, so it should be 
easy to convert it into .spec.

Vít

Remove retired packages

[Michael Schwendt]

On Thu, 24 Jan 2013 13:13:09 +0100, Vít Ondruch wrote:

>  Dne 23.1.2013 21:04, Bruno Wolff III napsal(a):
>  > One possiblity here would be to create a special package that 
>  > obsoletes all of the dropped packages from the last release (or two 
>  > depending on how far back you want to yum update from).
>  
>  Actually, this is cool idea IMO. Why this package does not exist yet? 
>  Rel-engs has to have list of blocked packages already, so it should be 
>  easy to convert it into .spec. 
It has been suggested, discussed and rejected many years ago. Here's
one thread from 2007,

  https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html

and I remember it has been a topic before for early FESCO, but probably
on IRC or the closed list. As one can see, we referred to it with the
term "garbage collection" for packages. That's why I managed to find this
thread, too.

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git1.1.fc19.x86_64
loadavg: 0.03 0.04 0.05

Remove retired packages

[Bruno Wolff III]

On Thu, Jan 24, 2013 at 14:18:25 +0100,
   Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
> On Thu, 24 Jan 2013 13:13:09 +0100, Vít Ondruch wrote:
>
> It has been suggested, discussed and rejected many years ago. Here's
> one thread from 2007,
>
>   https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
>
> and I remember it has been a topic before for early FESCO, but probably
> on IRC or the closed list. As one can see, we referred to it with the
> term "garbage collection" for packages. That's why I managed to find this
> thread, too. 
The above thread was sort of neutral. I think the downsides of making it 
harder to keep some dropped packages is out weighed by making yum upgrades 
work smoother.

Remove retired packages

[Matthew Miller]

On Thu, Jan 24, 2013 at 02:18:25PM +0100, Michael Schwendt wrote:
>  > Actually, this is cool idea IMO. Why this package does not exist
> yet? 
>  > Rel-engs has to have list of blocked packages already, so it should be 
>  > easy to convert it into .spec.
>  It has been suggested, discussed and rejected many years ago. Here's
>  one thread from 2007,
>    https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html 
Nice, because I was just going to say

https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00107.html


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Remove retired packages

[Vít Ondruch]

Dne 24.1.2013 14:18, Michael Schwendt napsal(a):
>  On Thu, 24 Jan 2013 13:13:09 +0100, Vít Ondruch wrote:
>
> > Dne 23.1.2013 21:04, Bruno Wolff III napsal(a):
> >> One possiblity here would be to create a special package that
> >> obsoletes all of the dropped packages from the last release (or two
> >> depending on how far back you want to yum update from).
> > Actually, this is cool idea IMO. Why this package does not exist yet?
> > Rel-engs has to have list of blocked packages already, so it should be
> > easy to convert it into .spec.
>  It has been suggested, discussed and rejected many years ago. Here's
>  one thread from 2007,
>
>     https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
>
>  and I remember it has been a topic before for early FESCO, but probably
>  on IRC or the closed list. As one can see, we referred to it with the
>  term "garbage collection" for packages. That's why I managed to find this
>  thread, too.
>  
Thank you for pointing it out. Was not aware of it.


Vít

Remove retired packages

[Michael Scherer]

On Thu, Jan 24, 2013 at 01:13:09PM +0100, Vít Ondruch wrote:
>  Dne 23.1.2013 21:04, Bruno Wolff III napsal(a):
>  >One possiblity here would be to create a special package that
>  >obsoletes all of the dropped packages from the last release (or
>  >two depending on how far back you want to yum update from).
>  
>  Actually, this is cool idea IMO. Why this package does not exist
>  yet? Rel-engs has to have list of blocked packages already, so it
>  should be easy to convert it into .spec. 
For the record, mageia does it, but not everybody is ok with that.

So you could talk to them to see if they have some interesting feedback on the topic.

-- 
Michael Scherer

[Kevin Kofler]

Bruno Wolff III wrote:
>  Note that this doesn't fix problems caused by dropped packages,
> that block
>  other packages from being updated. 
That's a problem for all upgrade methods, they might leave your system with 
broken dependencies instead of erroring out, but in the end the problem is 
always there. It's not solvable as long as we're as happy to drop packages 
as we are now, rather than keeping them working by rebuilding them even if 
there's no active maintainer.

>  One possiblity here would be to create a special package that
> obsoletes
>  all of the dropped packages from the last release (or two depending on how
>  far back you want to yum update from). 
Please no! Many of those packages keep working just fine. And where not, 
it's better to get a clear error message and to remove the offending 
packages manually and explicitly than to have the upgrade silently (well, 
with a one-line notice buried under many other lines of text) removing a 
package one may be depending on!

>  There are going to be some releases where you need to do things
> outside of
>  yum to upgrade. 
Then that's a problem with the feature which requires you to do that, and 
should be a showstopper! (Yes, I think UsrMove should not have been 
allowed.)

        Kevin Kofler

[Jóhann B. Guðmundsson]

On 01/23/2013 07:29 PM, Josh Boyer wrote:
>  On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav
> Reznik<jreznik(a)redhat.com>  wrote:
> > >= Features/FedoraUpgrade =
> > >https://fedoraproject.org/wiki/Features/FedoraUpgrade
> > >
> > >Feature owner(s):  Miroslav Suchý<msuchy(a)redhat.com>
> > >
> > >Upgrade Fedora to next version using yum upgrade.
>  I see no reason to make this an officially supported method to upgrade
>  Fedora.  The QA team is already swamped with work just getting the new
>  install tests done, and now fedup tests.  Having a third way of getting
>  a Fedora release onto a machine is going to expand the testing matrix
>  even more.  This isn't replacing something, it's just creating more
>  work.
>
>  Yum upgrade has always been possible but not supported.  Seems it can
>  stay that way. 
a)

QA was never asked when preupgrade got approved as an official upgrade 
method in the first place...


b)

We QA have alot of QA community members testing this so this does NOT 
require any additional effort or cause additional LOAD on the QA community.

c)

We ( QA )  already have discussed this and it takes minor criteria 
changed for us to implement this ( either or ).

yum upgrade is equally broken from my pov as preupgrade or fedup thus to 
me we can just as well "support" two failed upgrade mechanism or non et 
all.

It does not take a rocket scientist to figure out we cant probably 
"support" upgrading  until we default to brtrfs and users can rollback 
and boot into their old environment just incase heck our own so called 
default desktop does not handle upgrades very well.

So I say let's support both or non et all..

JBG

[drago01]

On Wed, Jan 23, 2013 at 11:47 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:

>  So I say let's support both or non et all.. 
Supporting "none" is not an option.
And the major issue with yum upgrades is that online upgrades can fail
not only based on what you have installed but also what is currently
running and it cannot handle stuff like usermove without user
intervention.

[Jóhann B. Guðmundsson]

On 01/23/2013 10:55 PM, drago01 wrote:
>  Supporting "none" is not an option. 
Really suddenly not an option.

We did that for a long time why is that suddenly not an option so please 
enlighten me why that's not an option.

Users are better of keeping /home on a separated partition and re-use it 
with an fresh install then those poor attempts to "support" upgrades one 
way or another which at this point in time we cant do since the bits for 
that aren't properly aligned to make that happen...

JBG

[Matthew Garrett]

On Wed, Jan 23, 2013 at 10:57:59PM +0000, "Jóhann B. Guðmundsson" wrote:

>  Users are better of keeping /home on a separated partition and
>  re-use it with an fresh install then those poor attempts to
>  "support" upgrades one way or another which at this point in time we
>  cant do since the bits for that aren't properly aligned to make that
>  happen... 
If you don't like what we produce, you're not obliged to use it.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[drago01]

On Wed, Jan 23, 2013 at 11:57 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  On 01/23/2013 10:55 PM, drago01 wrote:
> >
> > Supporting "none" is not an option.
>
>
>  Really suddenly not an option.
>
>  We did that for a long time why is that suddenly not an option so please
>  enlighten me why that's not an option. 
It was supported as long as fedora exists (and back in RHL days).

>  Users are better of keeping /home on a separated partition and re-use
> it
>  with an fresh install 
And loose all other configuration, having to reinstall every
application etc etc.

>  then those poor attempts to "support" upgrades one way
>  or another which at this point in time we cant do 
We can and always did.

>  since the bits for that
>  aren't properly aligned to make that happen... 
Works for me ... I always upgrade my systems ...  if it does not work
for you for whatever reason file bugs and don't claim that it is
inherently impossible because isn't.

[Michał Piotrowski]

Hi,

2013/1/23 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  On 01/23/2013 10:55 PM, drago01 wrote:
> >
> > Supporting "none" is not an option.
>
>
>  Really suddenly not an option.
>
>  We did that for a long time why is that suddenly not an option so please
>  enlighten me why that's not an option.
>
>  Users are better of keeping /home on a separated partition and re-use it
>  with an fresh install then those poor attempts to "support" upgrades one way
>  or another which at this point in time we cant do since the bits for that
>  aren't properly aligned to make that happen... 
? 8-)

I really can't imagine it.

I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.

>  JBG
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 


-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/

[Jóhann B. Guðmundsson]

On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
>  Hi,
>
>  2013/1/23 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
> > On 01/23/2013 10:55 PM, drago01 wrote:
> >> Supporting "none" is not an option.
> >
> > Really suddenly not an option.
> >
> > We did that for a long time why is that suddenly not an option so please
> > enlighten me why that's not an option.
> >
> > Users are better of keeping /home on a separated partition and re-use it
> > with an fresh install then those poor attempts to "support" upgrades one
> way
> > or another which at this point in time we cant do since the bits for that
> > aren't properly aligned to make that happen...
>  ? 8-)
>
>  I really can't imagine it.
>
>  I use Fedora as a server system for my daily developer work. I use
>  many services with different configurations. Actually updating it with
>  preupgrade/fedup is sometimes hard. Reinstalling whole system after
>  each release will be super painful.
>  
?

Keep your server configuration in git and keep the relevant data on 
separated partition then reinstall and checkout the config(s)

JBG

[Reindl Harald]

Am 25.01.2013 21:17, schrieb Jóhann B. Guðmundsson:
>  On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
> > I use Fedora as a server system for my daily developer work. I use
> > many services with different configurations. Actually updating it with
> > preupgrade/fedup is sometimes hard. Reinstalling whole system after
> > each release will be super painful.
> >
>  
>  ?
>  
>  Keep your server configuration in git and keep the relevant data on separated partition
> then reinstall and checkout
>  the config(s) 
which part of the configuration?
all /etc - well this would be more damage than resolution :-)

sorry but this does not work

i have made some hundret dist-upgrades with yum over the years
nearly zero downtime, normally not more as a kernel update with reboot

well, i keep all my systems 100% clear
but with reinstalls i had wasted so much more time

the big benefit (especially in VM environments) is that the update
goes so fast (as long you not install every bullshit) that the timeframe
is to short to make any troubles for running services

4-7 minutes per instance here since years

[Simo Sorce]

On Fri, 2013-01-25 at 20:17 +0000, "Jóhann B. Guðmundsson" wrote:
>  On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
>  > Hi,
>  >
>  > 2013/1/23 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  >> On 01/23/2013 10:55 PM, drago01 wrote:
>  >>> Supporting "none" is not an option.
>  >>
>  >> Really suddenly not an option.
>  >>
>  >> We did that for a long time why is that suddenly not an option so please
>  >> enlighten me why that's not an option.
>  >>
>  >> Users are better of keeping /home on a separated partition and re-use it
>  >> with an fresh install then those poor attempts to "support" upgrades
> one way
>  >> or another which at this point in time we cant do since the bits for that
>  >> aren't properly aligned to make that happen...
>  > ? 8-)
>  >
>  > I really can't imagine it.
>  >
>  > I use Fedora as a server system for my daily developer work. I use
>  > many services with different configurations. Actually updating it with
>  > preupgrade/fedup is sometimes hard. Reinstalling whole system after
>  > each release will be super painful.
>  >
>  
>  ?
>  
>  Keep your server configuration in git and keep the relevant data on 
>  separated partition then reinstall and checkout the config(s) 
Why should I do all this when I can simply apt-get upgrade^W^Wyum
upgrade ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Jóhann B. Guðmundsson]

On 01/25/2013 08:32 PM, Simo Sorce wrote:
>  On Fri, 2013-01-25 at 20:17 +0000, "Jóhann B. Guðmundsson"
> wrote:
> > On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
> >> Hi,
> >>
> >> 2013/1/23 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
> >>> On 01/23/2013 10:55 PM, drago01 wrote:
> >>>> Supporting "none" is not an option.
> >>> Really suddenly not an option.
> >>>
> >>> We did that for a long time why is that suddenly not an option so please
> >>> enlighten me why that's not an option.
> >>>
> >>> Users are better of keeping /home on a separated partition and re-use it
> >>> with an fresh install then those poor attempts to "support"
> upgrades one way
> >>> or another which at this point in time we cant do since the bits for that
> >>> aren't properly aligned to make that happen...
> >> ? 8-)
> >>
> >> I really can't imagine it.
> >>
> >> I use Fedora as a server system for my daily developer work. I use
> >> many services with different configurations. Actually updating it with
> >> preupgrade/fedup is sometimes hard. Reinstalling whole system after
> >> each release will be super painful.
> >>
> > ?
> >
> > Keep your server configuration in git and keep the relevant data on
> > separated partition then reinstall and checkout the config(s)
>  Why should I do all this when I can simply apt-get upgrade^W^Wyum
>  upgrade ? 
You do whatever floats your boat I prefer doing fresh installs and keep 
relevant data on their own partitions and configuration files in git you 
prefer to do it via yum or fedupgrade.

JBG

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  Users are better of keeping /home on a separated partition and re-use
> it
>  with an fresh install then those poor attempts to "support" upgrades one
>  way or another which at this point in time we cant do since the bits for
>  that aren't properly aligned to make that happen... 
Reinstalling all the time is a no go.

        Kevin Kofler

[Kevin Kofler]

drago01 wrote:
>  And the major issue with yum upgrades is that online upgrades can
> fail
>  not only based on what you have installed but also what is currently
>  running and it cannot handle stuff like usermove without user
>  intervention. 
1. That's a problem with UsrMove, not with yum!
2. UsrMove CAN be done online, e.g. with a C program (which won't care if 
you move ld.so under it after it's already in memory), or – with some 
trickery – even in shell. It was an explicit decision to require that 
useless dracut step.

        Kevin Kofler

[Bruno Wolff III]

On Wed, Jan 23, 2013 at 22:47:18 +0000,
   "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
> b)
>
> We QA have alot of QA community members testing this so this does NOT 
> require any additional effort or cause additional LOAD on the QA 
> community. 
Aren't they just testing an upgrade of the default install?

I don't think people are doing any automated testing of proper obsoletes 
for dropped packages, though most problems could probably be detected.
And this still doesn't handle dropped packages that are being replaced.

> yum upgrade is equally broken from my pov as preupgrade or fedup thus
>
> to me we can just as well "support" two failed upgrade mechanism or 
> non et all. 
Anaconda does some tricks that get packages installed even when there 
are problems that don't get handled by a normal yum update. (Or at least 
used to. (With the move toward not using special stuff in anaconda, maybe 
this isn't true any more.)

[Adam Williamson]

On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
>  On Wed, Jan 23, 2013 at 22:47:18 +0000,
>     "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
>  >b)
>  >
>  >We QA have alot of QA community members testing this so this does NOT 
>  >require any additional effort or cause additional LOAD on the QA 
>  >community.
>  
>  Aren't they just testing an upgrade of the default install? 
Correct:
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_des... is the only
current upgrade test case. 

We could plausibly extend the range somewhat to cover common package
loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
(non-US keyboard layout, encryption, a couple of different partition
schemes), for _one_ upgrade method. Anything beyond that would be a bit
of a stretch, I think.

>  I don't think people are doing any automated testing of proper
> obsoletes 
>  for dropped packages, 
Correct.

>   though most problems could probably be detected.
>  And this still doesn't handle dropped packages that are being replaced.
>  
>  >yum upgrade is equally broken from my pov as preupgrade or fedup thus 
>  >to me we can just as well "support" two failed upgrade mechanism or 
>  >non et all.
>  
>  Anaconda does some tricks that get packages installed even when there 
>  are problems that don't get handled by a normal yum update. (Or at least 
>  used to. (With the move toward not using special stuff in anaconda, maybe 
>  this isn't true any more.) 
fedup does not use anaconda in any way. anaconda didn't really do any
'tricks', IIRC, it just ran the upgrade in skip-broken mode. I don't
know if fedup uses skip-broken or not.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Lennart Poettering]

On Wed, 23.01.13 22:17, Adam Williamson (awilliam(a)redhat.com) wrote:

>  On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
>  > On Wed, Jan 23, 2013 at 22:47:18 +0000,
>  >    "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt;
> wrote:
>  > >b)
>  > >
>  > >We QA have alot of QA community members testing this so this does NOT 
>  > >require any additional effort or cause additional LOAD on the QA 
>  > >community.
>  > 
>  > Aren't they just testing an upgrade of the default install?
>  
>  Correct:
>  https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_des... is the only
> current upgrade test case. 
>  
>  We could plausibly extend the range somewhat to cover common package
>  loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
>  (non-US keyboard layout, encryption, a couple of different partition
>  schemes), for _one_ upgrade method. Anything beyond that would be a bit
>  of a stretch, I think. 
Wouldn't it make sense to test the "full install"? In contrast to other
distributions it should be possible to install all our RPMs at once
(modulo arch specific ones that is). If that thing upgrades properly,
then you have a pretty good chance it will work for most subsets too?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[drago01]

On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Wed, 23.01.13 22:17, Adam Williamson (awilliam(a)redhat.com) wrote:
>
> > On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
> > > On Wed, Jan 23, 2013 at 22:47:18 +0000,
> > >    "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt;
> wrote:
> > > >b)
> > > >
> > > >We QA have alot of QA community members testing this so this does NOT
> > > >require any additional effort or cause additional LOAD on the QA
> > > >community.
> > >
> > > Aren't they just testing an upgrade of the default install?
> >
> > Correct:
> > https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_des... is the
> only current upgrade test case.
> >
> > We could plausibly extend the range somewhat to cover common package
> > loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
> > (non-US keyboard layout, encryption, a couple of different partition
> > schemes), for _one_ upgrade method. Anything beyond that would be a bit
> > of a stretch, I think.
>
>  Wouldn't it make sense to test the "full install"? 
I doubt that you can install all packages without hitting conflicts.

[Stephen John Smoogen]

On 24 January 2013 10:25, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering 
> > Wouldn't it make sense to test the "full install"?
>
>  I doubt that you can install all packages without hitting conflicts. 
You can not. Lots of things conflict so if you try to do a 'yum
install *' you get a LOT of different conflicts from say stuff
requiring mod_ssl versus nss or gnutls etc.



-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

[Kevin Kofler]

drago01 wrote:
>  I doubt that you can install all packages without hitting conflicts.
That just shows again how Conflicts are evil and how we're way too tolerant 
about them. There should be NO conflicting packages in the official 
repositories.

        Kevin Kofler

[Adam Williamson]

On Thu, 2013-01-24 at 18:11 +0100, Lennart Poettering wrote:
>  On Wed, 23.01.13 22:17, Adam Williamson (awilliam(a)redhat.com) wrote:
>  
>  > On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
>  > > On Wed, Jan 23, 2013 at 22:47:18 +0000,
>  > >    "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt;
> wrote:
>  > > >b)
>  > > >
>  > > >We QA have alot of QA community members testing this so this does NOT 
>  > > >require any additional effort or cause additional LOAD on the QA 
>  > > >community.
>  > > 
>  > > Aren't they just testing an upgrade of the default install?
>  > 
>  > Correct:
>  > https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_des... is the
> only current upgrade test case. 
>  > 
>  > We could plausibly extend the range somewhat to cover common package
>  > loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
>  > (non-US keyboard layout, encryption, a couple of different partition
>  > schemes), for _one_ upgrade method. Anything beyond that would be a bit
>  > of a stretch, I think.
>  
>  Wouldn't it make sense to test the "full install"? In contrast to other
>  distributions it should be possible to install all our RPMs at once
>  (modulo arch specific ones that is). If that thing upgrades properly,
>  then you have a pretty good chance it will work for most subsets too? 
It's probably a useful test case to add, yeah, but I can think of
several scenarios where it wouldn't cover things (by definition it
probably wouldn't catch cases where a necessary dependency was missing
in an upgraded package, for instance :>). It helps to some degree to
cover against issues in the package set, but it still doesn't innoculate
us against configuration differences - hardware borking between kernel
releases, different partition layouts etc.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2013-01-23 at 18:04 +0000, Jaroslav Reznik wrote:

>  If this method will be tested by FedoraQA, then I believe this
> upgrade method 
>  can be safely recommended to user.  
On a practical level, this is not a good thing to rely on. It is
impossible for QA to cover the entire set of possible upgrades, or even
an appreciable fraction of it.

The upgrade testing we do can reliably expose major problems with the
upgrade mechanism itself, and - mostly - major problems in core and
commonly-used package scripts. It can never be relied upon to expose
anything beyond that; and any scenarios in which 'FedoraUpgrade' would
produce a worse result than fedup are likely to fall into this set.
Thus, QA testing of 'FedoraUpgrade' would not be a reasonable foundation
on which to build an assertion that it is a safe upgrade method, worthy
of recommendation to end users. 

Several knowledgeable developers have asserted that - while it often
happens to work out okay - online upgrading is an inherently dangerous
operation, I don't see that the limited amount of validation QA is able
to offer can possibly gainsay them.

Personally, I'd agree with several other responders that yum upgrade
should stay in its current status: we document it but discourage it.

(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Matthew Miller]

On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote:
>  (As a side note, I would like to avoid describing fedup as
> 'officially
>  supported' and describe it instead as 'officially recommended' - it's an
>  important semantic difference, I think.) 
Because we don't "officially support" anything, or because it has lesser
status than, say, doing a fresh install and preserving home?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Adam Williamson]

On Thu, 2013-01-24 at 08:56 -0500, Matthew Miller wrote:
>  On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote:
>  > (As a side note, I would like to avoid describing fedup as 'officially
>  > supported' and describe it instead as 'officially recommended' -
> it's an
>  > important semantic difference, I think.)
>  
>  Because we don't "officially support" anything, or because it has lesser
>  status than, say, doing a fresh install and preserving home? 
Because we don't 'officially support' anything, correct. When someone
files a bug on upgrade our usual response is not to fix it immediately
and try to help them recover their borked system, our usual response
tends to be to file it in the same place as Arthur Dent's local council
filed their bypass designs...

being less flippant, it's really just that upgrade is inherently an
operation that a project like Fedora can't really 'support'. It's always
going to be best effort and it's probably going to break for some
people. 'Recommend' just seems like a better verb. I would suggest this,
frankly, whatever the method in question is.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Chris Adams]

Once upon a time, Adam Williamson <awilliam(a)redhat.com&gt; said:
>  Several knowledgeable developers have asserted that - while it often
>  happens to work out okay - online upgrading is an inherently dangerous
>  operation, I don't see that the limited amount of validation QA is able
>  to offer can possibly gainsay them. 
The way some other Unix OSes I've used worked for version upgrades was
to require the admin drop to single-user mode first, optionally with
network access.  RHL/RHEL/Fedora have never had a "single-user with
network" mode, but that would be nice to have.  Then maybe "yum upgrade"
could require (or at least recommend) switching to that mode first.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Björn Persson]

Chris Adams wrote:
>  The way some other Unix OSes I've used worked for version
> upgrades was
>  to require the admin drop to single-user mode first, optionally with
>  network access.  RHL/RHEL/Fedora have never had a "single-user with
>  network" mode, but that would be nice to have.  Then maybe "yum upgrade"
>  could require (or at least recommend) switching to that mode first. 
Isn't that essentially what Fedup does?

Björn Persson

[Björn Persson]

Adam Williamson wrote:
>  (As a side note, I would like to avoid describing fedup as
> 'officially
>  supported' and describe it instead as 'officially recommended' - it's an
>  important semantic difference, I think.) 
Good idea. I've often wondered what it means that upgrading by Yum
isn't supported, as Fedora is said to be community-supported and the
community seems to be supporting Yum upgrades about as well as any
other aspect of Fedora.

Björn Persson