Bug 58797

Summary:	up2date is too inflexible
Product:	[Retired] Red Hat Linux	Reporter:	Chris Ricker <chris.ricker>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	low
Version:	7.3	CC:	gafton, mihai.ibanescu, srevivo
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-10-17 14:38:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Ricker 2002-01-24 20:39:39 UTC

up2date is very inflexible, and needs more options.  For example, I'm currently
trying to update a system to the RH 7.2 errata.  It's refusing to install the X
font errata because "configuration changed".

First of all, that shouldn't matter.  The only thing that's changed for
XFree86-100dpi-fonts and XFree86-75dpi-fonts is the encodings.dir file, which
will naturally be different since it's a generated file.

But, even given that particular bit of braindeadness on up2date's part, it
should still be possible to tell up2date to install the RPMs.  As far as I can
tell, it's not.

Even more braindead, though, is the fact that downloading only (up2date -d) also
fails to retrieve those two packages.  download only should at least be
configurable to download packages for which configuration has changed.

Comment 1 Adrian Likins 2002-01-25 02:59:56 UTC

>up2date is very inflexible, and needs more options.  For example, I'm currently
>trying to update a system to the RH 7.2 errata.  It's refusing to install the X
>font errata because "configuration changed".

The case for which up2date flags something as having a config modified is
basically:
     The file is flagged as a config file.
     The md5sum of the version on disk is different than the
          original md5sum of the file.
          (ie, the file has been modified)
     The md5sum of the file in the new package is different than 
         the original md5sum of the file in the old package.
           (ie, the default format of the file has changed)
     The file is not marked as "config(noreplace)"

      In all other cases, rpm is left to handle the config files. But
      In this circumstance, since:
           a) installing the new file may cause a local change 
               to be repealed

              or

           b) the old config file is used, but since the default config
              format has changed, the old config file may not with the new 
              package, potentially breaking something.

     Since up2date is designed to be used automatically and not interactivily
in many cases, these potentiall dangerous updates are skipped by default.

    To install the packages anyway, you can:

         a) run the interactive gui client and select the package from the
            presented list of skipped packages, overriding the default action.

         b) run `up2date --configure` and disable the config option of 
             "Do not upgrade packages when local configurations have been modifed"

         c) Run the client with the "--force" flag. Note: this also overrides
            package and file skip lists. 

    In this particular case, it looks like the config files in question should
of been flagged with the "config(noreplace)" option.


up2date will only download packages that it can correctly install according
to the config options set. (with the occasional minor caveat of packages that
fail a real install but pass a transaction run (a rpm with a file thats been
chattr +i'ed, for example). This is by design. 

A "--download-anyway-even-though-I-know-I-cant-correctly-install-these-packages"
config option is probabaly a reasonable feature request.

Comment 2 Chris Ricker 2002-05-09 14:27:44 UTC

Reopening as a RFE.  I still want the
"--download-anyway-even-though-I-know-I-cant-correctly-install-these-packages"
option ;-)

Comment 3 Adrian Likins 2003-08-06 22:24:01 UTC

"--download-anyway-even-though-I-know-I-cant-correctly-install-these-packages"
option added.

--get and --get-source, circa 3.1.40 or so

Comment 4 Chris Ricker 2003-10-17 14:38:41 UTC

closing as fixed, thanks