Upgrades from one major release to the next

[Tarjei Knapstad]

With the inclusion of fedora extras support in anaconda, has there
been any work done to improve upgrading between major releases? Here
are my thoughts on the subject in any case... :)

Whenever someone asks "Is it possible to update my FC4 installation to
FC5?" or the like, the answers are usually one of:

1.  You can do it through yum if you're careful to just follow this
lengthy guide <link to website>, but then again you probably
shouldn't.
2.  Yes, just use the Upgrade option in Anaconda (but you may run into
trouble because of stale packages, configs or whatnot)
3.  The best option is to just reinstall from scratch (you did make a
separate partition for /home, yeah?)

The first option is clearly a mine field and would be very hard to
support, so I think it should just be disregarded for now. I'd be more
interested in improving on the second option.

The current installation document only mentions that "Software which
you have installed manually on your existing Fedora Core or Red Hat
Linux system may behave differently after an upgrade.", which is fine
but doesn't really help the user in any way. As far as I can see, the
potential problems with an upgrade include:

- Some of your packages have been removed (or moved to Extras), and
some new ones might have appeared.

My experience with a FC3 -> FC4 upgrade (of an everything-install) was
that I was left with a lot of stale packages from FC3 and I missed out
on the new stuff like Eclipse on my upgraded FC4 install. Would it be
viable to add a "Review package differences" screen to Anaconda? It
would be nice to be presented with a list of new software that you may
or may not choose to install, as well as a list of stale packages that
you probably want to get rid of or find alternatives for in Extras or
other repositories.

- Your configurations may become invalid (both systemwide in /etc and
per user dotfiles/directories).

Systemwide configurations that are unchanged should probably just be
replaced by newer ones _if they are unchanged_, but I think the
current procedure just installs them as .rpmnew? Would it be possible
to rename the old ones as .rpmold.fc3 if this is the case?
Configurations that are changed by the user should of course not be
replaced, but I think they should be logged to a separate file in the
root account so that it's possible to review these for the user and
check that they're still valid. All this would require sha1 sums of
configuration files from old rpm's so I guess it's hard to implement.

The per-user configuration stuff is harder to deal with. I've had
sufficient trouble with this in the past to generally just get rid of
most (if not all) of my user configuration stuff, and just keep my
documents from /home. No good ideas here really...

- 3rd party software (like Maple in my case), and software that you
have built and installed yourself (worst case: ./configure; make
install) is likely to run into trouble. Maple is mostly "self
sufficient" when it comes to library dependencies, other things are
probably built agains system libraries and is likely to fail. I don't
know of any other solution to this than to warn the user that this
might be the case. Is there such a warning in Anaconda? Or only in the
installation guide?


As for the 3rd option, reinstall from scratch but keep /home, would it
be possible to improve on the suggestion for automatic partitioning to
also include a separate /home partition? If this was combined with an
upgrade option that clearly stated that it will swipe the system, but
keep your /home partition, I guess this would be the most comfortable
upgrade path for many home users. (I agree you should still backup
your data before attempting an upgrade, but why not make it a bit less
likely that you'll have to restore that backup :)).

I'd be interested to hear if anyone else has opinions here and like I
said earlier, if there's any extra effort that has allready gone into
alleviating the pain of upgrades I'd be interested to learn about it.

--
Tarjei

[Yuan Yijun]

2005/12/1, Tarjei Knapstad <tarjei.knapstad(a)gmail.com&gt;:
>  - Your configurations may become invalid (both systemwide in /etc and
>  per user dotfiles/directories).
>
>  Systemwide configurations that are unchanged should probably just be
>  replaced by newer ones _if they are unchanged_, but I think the
>  current procedure just installs them as .rpmnew? Would it be possible
>  to rename the old ones as .rpmold.fc3 if this is the case?
>  Configurations that are changed by the user should of course not be
>  replaced, but I think they should be logged to a separate file in the
>  root account so that it's possible to review these for the user and
>  check that they're still valid. All this would require sha1 sums of
>  configuration files from old rpm's so I guess it's hard to implement.
>
>  The per-user configuration stuff is harder to deal with. I've had
>  sufficient trouble with this in the past to generally just get rid of
>  most (if not all) of my user configuration stuff, and just keep my
>  documents from /home. No good ideas here really...
>  
If yum/rpm would send a detailed mail to all users indicate that what
configurations are saved to .rpmold, .rpmnew, etc. and what are
replaced then I could believe in yum/rpm more. Currently only packages
list are mailed to root account, so I have to run yum in
gnome-terminal and double or triple the screen cache in order to find
these information. I believe that package management should not be
interactive like debian, but still need to present these information
to users.

--
bbbush ^_^

[Jesse Keating]

On Fri, 2005-12-02 at 09:30 +0800, Yuan Yijun wrote:
>  If yum/rpm would send a detailed mail to all users indicate that
> what
>  configurations are saved to .rpmold, .rpmnew, etc. and what are
>  replaced then I could believe in yum/rpm more. Currently only packages
>  list are mailed to root account, so I have to run yum in
>  gnome-terminal and double or triple the screen cache in order to find
>  these information. I believe that package management should not be
>  interactive like debian, but still need to present these information
>  to users. 
IIRC the messages you see about .rpmsave and .rpmnew are issued by rpm,
not by yum.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating

[Jef Spaleta]

On 12/1/05, Jesse Keating <jkeating(a)j2solutions.net&gt; wrote:
>  IIRC the messages you see about .rpmsave and .rpmnew are issued by
> rpm,
>  not by yum. 
Indeed.... i wish there was  a way to log those messages in a
centralized way for review without having to screenscrape the stdout
scroll looking for them.  I don't even think graphical up2date had/has
a way to review those messages. I think you could only see them if you
ran up2date from a terminal..back in the day.

-jef

[seth vidal]

On Thu, 2005-12-01 at 20:58 -0500, Jeff Spaleta wrote:
>  On 12/1/05, Jesse Keating <jkeating(a)j2solutions.net&gt; wrote:
>  > IIRC the messages you see about .rpmsave and .rpmnew are issued by rpm,
>  > not by yum.
>  
>  Indeed.... i wish there was  a way to log those messages in a
>  centralized way for review without having to screenscrape the stdout
>  scroll looking for them.  I don't even think graphical up2date had/has
>  a way to review those messages. I think you could only see them if you
>  ran up2date from a terminal..back in the day. 
There's a way - it's been on the long list on yum for a while now to
capture them for logging.

-sv

[Matthew Miller]

On Thu, Dec 01, 2005 at 10:40:08PM -0500, seth vidal wrote:
>  > scroll looking for them.  I don't even think graphical
> up2date had/has
>  > a way to review those messages. I think you could only see them if you
>  > ran up2date from a terminal..back in the day.
>  There's a way - it's been on the long list on yum for a while now to
>  capture them for logging. 
Yeah I suck 'cause I keep promising to work on it.

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>

[Jason L Tibbitts III]

> >>>> "YY" == Yuan Yijun
> <bbbush.yuan(a)gmail.com&gt; writes: 
YY> If yum/rpm would send a detailed mail to all users indicate that
YY> what configurations are saved to .rpmold, .rpmnew, etc. and what
YY> are replaced then I could believe in yum/rpm more.

I use the following script, which will tell you about any rpmsave or
rpmnew files and can spam you with diffs as well.

#!/usr/bin/perl
use Getopt::Std;
getopts('dq');

$| = 1;
@DIFF = qw(/usr/bin/diff -u);
@LS   = qw(/bin/ls -l);

@configfiles = `rpm -qac`;

for $i (@configfiles) {
  chomp $i;
  $old = -f "$i.rpmsave";
  $new = -f "$i.rpmnew";
  if ($old || $new) {

    # If running quietly, we can just exit the first time we see a difference
    if ($opt_q) {
      exit 1;
    }

    $package = `rpm -qf $i`;
    chomp $package;

    push @{$updates{$package}}, {file => $i,
				 old  => $old,
				 new  => $new,
				};
  }
}

exit 0 unless %updates;

for $package (sort keys %updates) {
  print "Updated files in package $package:\n";

  for $i (@{$updates{$package}}) {
    if ($i->{old}) {
      show ($i->{file}, "$i->{file}.rpmsave");
    }
    if ($i->{new}) {
      show ($i->{file}, "$i->{file}.rpmnew");
    }
  }
  print "\n";
}

exit 1;

sub show {
  my($old, $new) = @_;

  print "    " if $opt_d;
  system(@LS, $old);
  print "    " if $opt_d;
  system(@LS, $new);

  if ($opt_d) {
    print "Differences:\n", "="x40, "\n";
    system(@DIFF, $old, $new);
    print "="x40, "\n";
  }
}

 - J<

[Yuan Yijun]

2005/12/2, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt;:
>  >>>>> "YY" == Yuan Yijun
> <bbbush.yuan(a)gmail.com&gt; writes: 
Sincerely speaking I don't like to be called YY~~ (nor BB, MM alike
please....What mail client are you running?)
And I don't know if your script could help me, when and how frequently
will you run this spam generator? After each yum cron job? :) Anyway,
thank you very much!

--
bbbush ^_^