Bug 55643 - up2date should not keep .hdr even with keepAfterInstall=1
up2date should not keep .hdr even with keepAfterInstall=1
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-03 16:30 EST by Aleksey Nogin
Modified: 2015-01-07 18:52 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 20:13:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2001-11-03 16:30:40 EST
Currently with keepAfterInstall=1, up2date keeps *everything*, not just RPM
packages. However it seems silly and unnecessary to keep the .hdr packages,
even when keepAfterInstall=1
Comment 1 Adrian Likins 2001-11-05 17:32:07 EST
hmm, indeed. 

I'll see if I can fix that in the next version.
Comment 2 Bill Crawford 2001-11-06 08:42:28 EST
Plea for the opposite: caching the .hdr "packages" is quite important when a)
you have a slow or busy connection, b) the up2date server(s) have a slow
(congested) connection, and/or c) there are quite a few of them.

Perhaps a setting on how many to keep, like a maximum cache size?
Comment 3 Aleksey Nogin 2001-11-06 09:46:53 EST
Right now .hde packages are *never* reused, even when kept. If you think they
should be, you should probably file a different RFE for that. 

We could do something like
keepAfterInstall=0 => nothing kept
keepAfterInstall=1 => only RPMs are kept
keepAfterInstall=2 => both RPMs and .hdr are kept (files like
redhat-linux-i386-7.2.20011031233847 should still be removed).

OTOH, I don't think it's worth keeping .hdr when .rpm is already there! It would
probably be a better idea if up2date could just skip .hdr download and use .rpm
for queries when .rpm is already there (the added bonus is that it's simple to
check that the .rpm is authentic by using the GPG sig, but it's harder to check
the authenticity of an existing .hdr).
Comment 4 Mihai Ibanescu 2001-11-06 11:06:50 EST
ayn2: I think you are wrong, up2date does use the already saved .hdr instead of
re-downloading them. And yes, if up2date does find the rpm, it will use it
instead  of the header.

This is true for Red Hat 7.2 up2date, not sure about previous versions
Comment 5 Adrian Likins 2001-11-06 14:58:03 EST
left over .hdr file could be used, but then, if you already downloaded
the .hdr, then the package, and installed the package, you shouldnt
ever need the hdr again (the same info should now be in the rpm
database).

If only the rpms are available (either in /var/spool/up2date, or in
a path specified via -d) up2date will read the header from the local
rpm instead of downloading the remote header again. 

There isnt really any need to keep the .hdr files around after the app
is finished. The fact they arent deleted is probabaly a bug. (need to
reverify that that doesnt break anything, but I'm pretty sure it doesnt).
Comment 6 Aleksey Nogin 2001-11-09 19:35:28 EST
It appears that even when both .rpm and .hdr are there, up2date still
re-downloads the .hdr (at least the timestamp of the .hdr changes).
Comment 7 Aleksey Nogin 2002-01-04 18:48:00 EST
> And yes, if up2date does find the rpm, it will use it instead of the header.

Just tried it with latest up2date (up2date-2.7.11-7.x.2), it still re-creates
.hdr even when the .rpm are present.
Comment 8 Todd Warner 2004-08-26 20:13:18 EDT
2 plus years old. Closing. Reopen if there is an issue over this.

Note You need to log in before you can comment on or make changes to this bug.