Bug 55643 - up2date should not keep .hdr even with keepAfterInstall=1
Summary: up2date should not keep .hdr even with keepAfterInstall=1
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-11-03 21:30 UTC by Aleksey Nogin
Modified: 2015-01-07 23:52 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-08-27 00:13:18 UTC
Embargoed:


Attachments (Terms of Use)

Description Aleksey Nogin 2001-11-03 21:30:40 UTC
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 22:32:07 UTC
hmm, indeed. 

I'll see if I can fix that in the next version.

Comment 2 Bill Crawford 2001-11-06 13:42:28 UTC
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 14:46:53 UTC
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 16:06:50 UTC
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 19:58:03 UTC
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-10 00:35:28 UTC
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 23:48:00 UTC
> 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-27 00:13:18 UTC
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.