On 11/29/05, Benjy Grogan <benjy.grogan@xxxxxxxxx> wrote: > Yeah, that's what I'm starting to think. Having to have the initial rpm on > your hard drive all the time would be another kind of waste. > > It comes down to more fundamental changes. If the method of keeping rpms on > your hard drive is ditched then you're left with sending pure binary patches > to the actual files. That's the best way, but a complete reorganization is > then needed. > > Sounds like one of these long projects that requires corporate funding to > see it through a few years work. I think it's an important enough challenge > to tackle that Red Hat, IBM and Novell should work together to do this. > > It's alot of work any way it's done. Best to go for the best solution and > find some backing and then hope everyone interested shows up to help out. > > Benjy, > AWWTF > I wonder if is possible to build a multipart rpm format, so by looking at it's header you could determine you only need the first x bytes, which would be the incremental binary patches between it and the last couple of versions (depending on how much extra space you want to take up). It might be possible to mark this first part so it will be ignored by earlier versions of yum/rpm. Can someone with a good understanding of the rpm format and how it is parsed comment on this idea? I am thinking something like this: [|header|incremental_patch_1|incremental_patch_2|...|]|normal_rpm_data Where the stuff in [] is (if possible) formatted so the current rpm system ignores it. Depending on what percentage of the filesize you want to take up with binary patches, there will be anywhere from 0 patches (and no header since it's not needed), to a patch between every previous version (if they're only a couple of kb each, it shouldn't hurt). The header would contain the offsets for all the patches, sha1 sums of each piece, and version numbers so the reader could determine which ones it needs. If missing one of the patches it would just proceed to download the whole rpm and update normally. Each patch should have hashes for each file that needs updating and if any one of these don't match the files on the disk, it proceeds to download the rest of the rpm and update normally. I don't know if I agree that this needs corporate funding and years of work. I think a system like this could be written in under a year by volunteers. n0dalus. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
