Jesse Keating wrote:
This then says to me that packagers ought to be completely static and not dependent on anything, so that we can actually perform an upgrade on them first and then upgrade everything else. Or alternatively, we load a static version to complete the upgrade and then update to the shared version.On Fri, 2009-03-20 at 14:48 -0400, Gerry Reno wrote:My perspective is from the user point of view. If the user is upgrading to a new release let's say and the process goes along for quite a while and then decides to bomb out because the rpm version needed to be newer then the user becomes confused. The software should take care of this. So if any package in the whole update requires a newer yum/rpm then I think yum should go do that first.Upgrading to a new release is precisely when this will fail. The "new yum" and "new rpm" would require all the other new packages in order to be functional. There is no way to use the new yum without the rest of the new stuff.
To require that the user remember to perform certain preupgrade procedures is just asking for lots of user frustration. Even if you put it in bold geezer font you will always have users who just forget, or get confused and don't do it. The better way is to create software that takes care of these things and gives the user a better experience.