Call for comments - RPM upgrade

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 10 November 2003 23:19, Warren Togami wrote:
> It is my opinion that RH8 and RH9 should be upgraded to the latest
> versions for the respective distros.  Regarding Barry K. Nathan's
> concern about the epoch promotion problem, could you please post a
> concrete example of what triggers that problem?  The entire list needs a
> refresher about exactly what this problem is.
>
> (Also I believe there was some config option that we could toggle to get
> the old epoch behavior back.  We will determine through your concrete
> example and further discussions if switching this option will be
> needed.)

Ok, so there is good sound technical reason to bump rpm on RHL8 and 9.  I 
can live with that, as I think the rest of the list can.

> We should eventually put up 7.2 and 7.3 for a vote after we have a
> thorough analysis of the technical improvements in the latest rpm-4.0.5
> release.  It is true that RPM was less problematic back then, but my
> main concern is the broken nature of rpmvercmp in those older versions.
>   In those old versions, whenever rpm compared a number to a letter, or
> letter to letter, it would trigger the "two way upgrade" problem which
> is bad.  Additionally rpm-4.0.4 had *some* deadlock issues that are
> probably gone in the upgrade version.  (Do testing.)
>
> Before ANY rpm upgrade happens, we will need to do much testing if the
> RPM upgrade breaks any 3rd party tools including apt-get, yum, Red
> Carpet and perhaps others.  In some cases users may need a compatibility
> library like the rpm 404 compat library provided with the rpm-4.1.1
> upgrade for RH8.

Ah, ok.  Other issues I see is trying to get yum the same across the board.  
THere isn't an updated version of yum for the 7.x series, but there are 
some nice new features, such as handling of src.rpms and whatnot, plus 
bugfixes.  This would be my main push for upgrading rpm on 7.x

> Two more long term notes:
> 1) Some have suggested a rewritten rhn_applet and up2date for RH7.3, RH8
> and RH9.  They suggested that after RHN stops providing software update
> services, perhaps a community based notification service could take its
> place.  I personally think a centralized service may have trust issues
> like "would you trust your server package information with total
> strangers?"  The next best thing would be a host-based service that
> daily checks for updates, then sends notification e-mail to the sysadmin
> if updates are available.  The notification e-mail recipient address and
> possibly SMTP server would then be configured during firstboot and
> System menu.

I would prefer to just go forward with yum/apt.  Yum in particular.  The 
yum that we offer for Legacy will be pre-configured with a bunch of 
mirrors in the config file (end user can uncomment the ones they want to 
use), and the cron job can be set up to not auto-update, but instead send 
an email to "root" with a list of available updates.  Again, the user can 
comment out the notice, and uncomment the auto-update line that will 
already be there.

> 2) Before I forget about this... in our RPM upgrade instructions for RH8
> and RH9, the docs should mention turning off all services that could
> cause RPM database contention.  That would mean the RHN applet, rhnsd,
> Red Carpet's daemon, yum's cron thing, or anything else that could
> possibly touch the RPM database during rpm upgrade.  This would lessen
> the chance of RPM deadlocking during the rpm upgrade.  After the upgrade
> it can be safely turned on again.

A very good point.

- -- 
Jesse Keating RHCE MCSE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam		(www.mondorescue.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/sQKS4v2HLvE71NURAu3NAKCCYAV23Fs/xAnvcyVO8Rd4DNn3kQCgrw3u
oKJaenbRvDCpDxbZHUe60rE=
=Ehnq
-----END PGP SIGNATURE-----