Bug 143254
| Summary: | RFE: "patch" rpms to reduce downloads / unnecessary "updates" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | David Anderson <david> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | nobody+pnasrat |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-29 09:58:23 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
David Anderson
2004-12-17 19:07:11 UTC
I've now done a more extensive search in Bugzilla; other requests are: 7121 : 1999-11-18 : WONTFIX 64053 : 2002-04-24 : DEFERRED 103205 : 2003-08-27 : NEEDINFO The last is interesting as it has a patch from SUSE attached. Objections seem to cluster around the following: 1. Packagers may not be competent enough to handle the extra complexity. (My response: I have a suggestion below that has little complexity - no changes to spec files and no extra skills needed). 2. SUSE's patch for RPM 4 wasn't "well tested" (this is 16 months ago), and there are extra complexities to deal with. (My response: I don't know if it is now well tested or not). 3. Philosophical objections to the whole concept. (My response: I believe philosophical objections would only apply against a "patch" concept that integrates to RPM at the wrong level). I have an idea for how to implement patch RPMs that wouldn't necessitate major re-working of RPM itself; no changes to spec files, no new skills necessary to learn. Just reduced downloads and CPU churn! a) Create a new program to generate a "patch RPM"; its input would be the old RPM, a new RPM, and a list of files that are changed (i.e. in both RPMs, but different in substance - e.g. as a result of bug fix). The program would then auto-discover (by examining the RPMs) the list of files that have been deleted, and those that have been added. The created "patch" could then have binary diffs also to further save bandwidth. - Modify rpm installation/updating as follows: if one of the RPMs to install is a patch, do this: * Verify that installed package has correct checksums, etc - otherwise, complain. (This is only necessary if binary diffs are being used). * Create a new RPM in a temporary directory by combining the installed RPM and the patch to recreate the original "new" RPM. * Behave as if the request was to update to the recreated new RPM, and forget that it originated from a patch. Under this method, there's little complexity; the update RPM is re-constructed at an "early" stage - the core RPM software never needs to know or care that there was originally a patch, or that patches even exist. The downside to this method is that there's no way to roll back just the patch; you'd have to download the original RPM. However, that's the way it is now in any case, so there's no loss - just not an optimal gain. Hi, Here is conversation on the rpm-devel list that gives some insight about what Jeff Johnson is thinking of doing regarding patches: https://lists.dulug.duke.edu/pipermail/rpm-devel/2004- December/000154.html Concerning your last statement, you can rollback rpms presently today without downloading the version you wish to rollback to. At least for my company this is a very important feature. That said I believe it is possible to provide what your looking for without overly complicated rollback mechanisms. That said, I am only a hacker in the shadows, and not a RH employee. Cheers...james Regarding rollback - I ought to read the man page more carefully to learn how to do it properly! I removed an rpm with --repackage last week (on Fedora Core 2), but trying to reinstall it gave errors about signature; I tried to install without signature or package checksums but it complained about the checksums of individual files within the package, at which point I gave up and downloaded the original RPM again to save time in working out what I should be doing. :-( Patch packages add a great deal of complexity to package installs and are unlikely to be able to be used generally or widely. The far better solution is deltas on *.rpm packages, which can be done with all existing packages right now. OK... I'm using up2date to get updates from RHN on RHEL 3 - how do I get it to do "deltas on *.rpm packages" ?? I'd love to reduce my 500Mb download on a 512kbps line. In response to #4 I'd also say: - The complexity is all yours! This is a RHEL bug; to update, we just run up2date and click a few boxes. Isn't it RH's job to deal with the complexity rather than make the users suffer? Isn't that what we pay for? - If patch RPMs were able to be used by up2date, then they would be used everywhere where up2date is used - i.e. everywhere where RHEL is updated. I don't really understand how to use "deltas on *.rpm packages" to update our RHEL 3 install, so if anyone can enlighten me, I'd be very thankful! Cheers. I've now read a bit more on this problem... I think I now understand that by "right now" you don't mean that I can do it right now on RHEL 3, but that it can be on RPMs that already exist (i.e. they don't need to be rebuilt). Sorry for my ignorance/timewasting... |